(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 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.