Nitpick: It seems like instead of using the extra shouldOverwriteButtonTitle variable, we could use the if-else statement above to set unsupportedBlocksButton.

This would make us declare unsupportedBlocksButton as let right?
I thought shouldOverwriteButtonTitle name would also give some context of the reasoning for the undefined.

Would you say something like this?

let unsupportedBlocksButtonTitle = undefined;
if ( unsupportedBlockEditor.supported === false && unsupportedBlockEditor.switchable ) {
    unsupportedBlocksButtonTitle = __( 'Open Jetpack Security settings' );
}

Yes I think I had something like that in mind.

Nitpick: An alternative here could be to use:

	const { 
		unsupportedBlockEditor = false,
		unsupportedBlockEditorSwitch = false
	} = getSettings( 'capabilities' ).unsupportedBlockEditor;

unsupportedBlockEditor.supported and unsupportedBlockEditor.switchable I think gives a nice context on their usage. Like:

if (
 	unsupportedBlockEditor.supported === false &&
 	unsupportedBlockEditor.switchable
 )

vs

if (
 	unsupportedBlockEditor === false &&
 	unsupportedBlockEditorSwitch
)

What do you think?

(By the way, I think this whole file is a mess anyway, and not much extendible if we add more strings in the future. We will probably split it in the future)

Ideally, those attributes (unsupportedBlockEditor and unsupportedBlockEditorSwitch) would be descriptive enough on their own so that they can be deconstructed and used as-is without needing to be renamed. But I know it's hard here to find a good name, so I'm happy to leave it as-is if you want to.

Just asking out of curiosity. We have a lot of explicit bool checks in this file (i.e., someValue === true and someValue === false). Are we doing that to guard against a cases where someValue could be some other truth-y or false-y values, or is it a style preference to do the explicit bool check instead of doing something like someValue (or even !!someValue if we needed a bool) and !someValue, or maybe there's another reason?

Just asking because I tend to use the !s when I can (I find them more readable), and I'm curious if there are considerations I may not be considering when I do that. I'm not asking because I think we need to change it here. 🙂

Nitpick: I think just using 2 variables instead of grouping them in an object is just simpler and easier to understand, especially since you're assigning an unsupportedBlockEditor to a supported property

Nitpick: I would expect that, given its name, addStrings would accept a list of strings as parameter. The fact that it accepts a function returning a mapping of (string id, string value) makes it a bit hard to grasp imo.