Deactivating block controls

I’ve a similar issue to @ja4st3r on this post – https://www.ads-software.com/support/topic/deactivate-gutenberg-block-controls/ but want to ask a broader question:

I typically work with designers who want more functionality and specific designs than the core editor can currently give, but I advocate for the core editor as it
– avoids layering a separate builder system on top (with all those overheads)
– sunsetting WYSIWYGs means an ACF flexible fields won’t cut it anymore
– where it works, I feel it gives a fairly intuitive interface.

However the increase in inlining styles, without opting in, has damaged previous site layouts for me (and were painful to track down & fix). One stated aim for FSE and the block controls was to give a user the ability to style without CSS, but for built sites where correct css was in place, triggering inline styling off container classes regardless of context threw out stable layouts (since fixed with more !importants and overly specific css). Further to that, additional controls – for example colour and typography – have also appeared. While I’ve learnt to restrict them in current builds, some previous clients have been a little too – how to say it? – playful with them, detracting from the overall design.
I’m concerned that the core editor might not only have been a bad decision for previous builds but may continue to evolve layout breaking options for current projects.

The theme.json seems like the best effort so far to group options for block controls but isn’t keeping pace: many options are apparently not integrated and seem over-engineered (and so useless for a bear of little brains like me)
– block variants are still php registered / deregistered
– the styles seem spread across “settings: custom” and “styles” in the json
– additional parameters appear locked away in the block.json files
– ideally simple class names are replaced with complex skewered ‘custom’ properties --wp--custom--{key}--{nested-key}: {value};
– removing some block control tabs need multiple sub-groups removed (see color on a button below). Presumably a future update (radialgradient? or ‘fluid’ font sizes in typography) could cause the tab to reappear again?

"settings": {
    "blocks": {	
         "core/button": {
		"color": {
			"background": false,
			"gradients": [],
			"text": false
		}
	}
}

I feel the transposition of css into json is pretty taxing and would rather avoid inlining styles. The inability to turn off a ‘tab’ in one go (and have it stay turned off) is frustrating, as is the worry that a new addition may give existing clients design breaking layout options.

So the questions:

1. If a theme.json is the direction of travel, is it fit for production today?
2. Is there an ability to opt-in to block supports – in one go – rather than opt out of each (a master switch!)?
3. Is there an ideal path to creating a templated site, restricting further customisation, and if so is there documentation that could be considered canonical?

I’ve come across some nuclear options for (2) in other posts (such as in
https://www.ads-software.com/support/topic/deactivate-gutenberg-block-controls/ ) or unregistering / hiding all core blocks and registering near duplicates in the theme but I’m aiming to avoid hacky as a starting point.
If (3) is answered with the link to https://developer.www.ads-software.com/block-editor/reference-guides/theme-json-reference/theme-json-living/ – I think the answer to (1) is emphatically ‘no’.