(I've worked on FSE, Gutenberg, and WordPress as a contributor, though it's been a couple years since I worked on FSE.)
I think there is a bit of a misunderstanding here. The WordPress block format is HTML so that it's completely portable and compatible with anything that uses HTML. The block markup (in HTML comments, can include JSON for individual settings that aren't explicitly HTML content) is a form of progressive enhancement that powers the editor. Sure, it's a bit of a hack, but that's just how the data is stored in the database. When you write or work with blocks, you don't manually write out this stuff.
FSE just builds on top of that to replace the PHP theme templating system (and it's still a young project, and lots of stuff is still maturing). Previously, end-users had very limited customization options, unless the theme author explicitly coded a ton of flexibility into the theme itself. Great for a theme author who wants the theme to be exactly the same everywhere, not great for a non-technical person who wants to set up their site exactly how they want.
The source of truth for templates is the database, after you start customizing the theme. Once you're customizing the theme, it's mostly expected you'll be in the editor, and won't be interacting with these underlying systems. For styling, it's a similar story. A lot of styles are powered by the global style system, where you define a lot of customizable presets (like colors) in JSON, which end-users can customize as they like.
I think it's important to recognize that the block editor is primarily developed with end-users in mind. After all, one of the biggest goals is to provide a flexible system that lets users edit their site in a GUI. (Which makes it a modern experience compared to other WYSIWYG editors!) It's definitely fair that this is a big shift over the previous approach, where you had to write PHP to do everything. But legacy themes still work fine, they just aren't normally flexible for users.
I had a WP site for many years. One day the company who made the custom theme I was using decided to drop support for it. I figured it was time to just switch to the built-in theme for easy of maintenance purposes. I used the 2022 (or was it 2023) theme.
The new editor was incredibly frustrating to use. I thought I must be doing something wrong but no, confirmed by reddit and youtube, it was a huge step backwards in many ways. One of the top downloaded plugins is the 'classic editor' which lets people use the old school editor.
The craziest thing to me about the fall from grace is that the new editor was likely a response to increased competition from wix, squarespace, etc. Those sites editors can almost be used by grandma. Wordpress on the other hand requires a phd in wordpress now. Were any user studies conducted?
According to google trends, Wordpress usage peaked a couple years ago and in my uninformed simpleton opinion would lay the blame at the feet of the redesign.
I'm not bitter about the situation (although I did waste a lot of time fighting the new UI to get it to do what I want) but I am disheartened because wordpress has been a pillar for the internet for so long I want it to succeed.
WordPress got into 'this' state because the modern frontend is in 'this' state itself.
For a decade now people kept criticizing WordPress for 'not being modern' and pushed all the ills that the modern frontend is afflicted with onto the project. They eventually caved in and added some 'modernity' to the project.
But not after ~4 years later, the zero-interest economy ends, stock values plummet, VC money dries up and organizations and people start looking for efficiency in their stacks to cut development and cloud costs, and voila - server-side rendering is cool again, serving static pages or plain HTML to the users is better and it turns out that our frontend stack has become unnecessarily complicated and not every app or site needed total DOM manipulation capabilities.
But the damage was done - React made its way into WP which already had well-fleshed-out, long-existing code and systems that were fulfilling all the purposes it and its users needed and complicated everything.
It feels like this is happening because mainstream tech is adopting WordPress more and bringing its biases and preferences to its community:
I see people asking about how they can rip off the WordPress frontend and use it as a 'headless cms' with a react or another complicated frontend that they absolutely don't need to use for the purpose they intend to build their site or app: Ie you're just making a custom e-commerce site. You arent going to pitch to VCs who may care about this kind of stuff, you are going to sell to actual end users who don't give a crap about your stack or what's behind it. WordPress already runs 30% of all e-commerce sites on the web with what it has, what benefit using react in the frontend of your new e-commerce store will bring you? When asked, they say that its 'more modern'. Doing something complicated and flipping backwards to do the same thing that WP already does out of the box with a plugin like Woocommerce to do it 'more modern', which the customers who buy stuff on the site will abso-freaking-lutely wont notice or care about.
This feels like an additional proof of how the influx of unbounded investor and VC cash enabled by a bloated stock market riding on zero-interest economy caused mainstream tech to become complex for complexity's sake - organizations became more like grad schools that do research than actual companies that serve end users, ending up creating a developer culture that does things in the most complex way possible without a justifying business reason.
I've been using Wordpress for 14+ years for personal use and 6+ for business use, and in the last 6 years I've always used Elementor as a page builder, for all my different needs: ecommerce websites, landing pages, blogs, portfolios..
I think there is a bit of a misunderstanding here. The WordPress block format is HTML so that it's completely portable and compatible with anything that uses HTML. The block markup (in HTML comments, can include JSON for individual settings that aren't explicitly HTML content) is a form of progressive enhancement that powers the editor. Sure, it's a bit of a hack, but that's just how the data is stored in the database. When you write or work with blocks, you don't manually write out this stuff.
FSE just builds on top of that to replace the PHP theme templating system (and it's still a young project, and lots of stuff is still maturing). Previously, end-users had very limited customization options, unless the theme author explicitly coded a ton of flexibility into the theme itself. Great for a theme author who wants the theme to be exactly the same everywhere, not great for a non-technical person who wants to set up their site exactly how they want.
The source of truth for templates is the database, after you start customizing the theme. Once you're customizing the theme, it's mostly expected you'll be in the editor, and won't be interacting with these underlying systems. For styling, it's a similar story. A lot of styles are powered by the global style system, where you define a lot of customizable presets (like colors) in JSON, which end-users can customize as they like.
I think it's important to recognize that the block editor is primarily developed with end-users in mind. After all, one of the biggest goals is to provide a flexible system that lets users edit their site in a GUI. (Which makes it a modern experience compared to other WYSIWYG editors!) It's definitely fair that this is a big shift over the previous approach, where you had to write PHP to do everything. But legacy themes still work fine, they just aren't normally flexible for users.