As a custom themer and php dev, I threw myself into learning block creation a couple years ago, surmounted the biggest learning hurdles... and then decided that creating blocks for clients was a bad idea.

First, the editor code was changing too fast. With much effort I'd created a new subhead block that would appear below the title in the editor but save data to post meta. It took me countless hours to figure out that my block wasn't working because post types have to support custom fields or the editor won't save to meta. Then as soon as I finished it, the source = meta feature was already deprecated. My clients don't want to pay an arm and a leg for maintenance, and I don't want to build something that will break in a year. The php I write is really stable.

Second, the block editor hasn't had anything akin to php templating, where the layout is consistent (and updatable!) but the content is filled out on a per post basis. Blocks are deliberately designed so you can't update the html and have it apply everywhere. Reusable blocks have the same content. Maybe block templating is at least approaching this? But templates aren't designed for post content as far as I know.

Last, particularly with the poor documentation, the learning curve is high enough that I'd have to be making blocks somewhat regularly to really get comfortable with it. If I was a full time dev and not also a designer etc that might be viable, but as is, it simply isn't. My clients don't need custom blocks often enough.

I haven't used ACF blocks yet because it doesn't offer the editor's visual interface (though I agree with Stephen that sometimes form fields are better). Instead I've been sticking with styles, patterns, variations, and php for now, and hoping the whole dev situation will improve. This proposed solution certainly looks like a smooth on ramp and I've love to try it, but it won't fix everything because the issue isn't just that initial learning hurdle or that php devs aren't interested in trying new things.