Allowing those widths on every block do not preclude explorations into refactoring alignments and layout features, but should be seen rather as a bit of consistency across the controls.
So as to not explode the width of block toolbars, wide and fullwide controls should probably not be part of the block toolbar of every block. The heading block just fits it, but the list block would not:

For that reason, the width controls should probably default to living in the block inspector, and then for blocks where it remains a primary action, they could be in the block toolbar. For the Paragraph block, for instance, the width controls are definitely secondary, whereas for an Image, it remains a primary interaction.
@jasmussen What are your thoughts on blocks like navigation link, social icon and button?
I feel like these inner blocks that are styled more as inline elements might be the exception to the rule of adding these controls everywhere.
Oh excellent point, it makes no sense for those innerblocks. I suppose we'll still want to keep the opt in or out and balance it on a per-block basis. Though instead of, as we've done now, reserve it for very few, just be inclusive of blocks instead.
Another thing to ensure is for context / themes that don't have wide / full width that the whole control should not render
I wanted to note that I've heard feedback from a number of developers frustrated that the code block is limited by the width of the main column. Especially for debugging long lines of code, and in absence of wrapping, that quickly gets frustrating. Allowing wide and full-wide options on that block would alleviate a fair bit of that frustration.
Most helpful comment
Another thing to ensure is for context / themes that don't have wide / full width that the whole control should not render