I found his vision compelling, and look forward in hopes it can be realized.

However, he made one statement that I find very worrisome, as someone who has literally spent the past month on two different MySQL data merging and cleanup projects with over a GB of content each:

Blocks are also able to save attributes in meta fields, if needed, granting continuity to existing features. Overall, the concept of the block is not about where it stores data, but how the user interacts with it.

The worrisome part is that his statement implies that meta fields will be the proverbial "red headed stepchild" when compared to structured data in $post->post_content. And from that I am concerned that most WordPress authors will end up storing independent data in post_content rather than in meta fields because they won't know any better.

Why does this matter? It is effectively impossible for create reliably WHERE clauses in SQL on the structured data that will be found into post_content. And it is effectively impossible to reliably update MySQL data using SQL UPDATE statements into a structure post_content.

The project I just worked on for one (1) month would have taken three (3) months if not more had much of that data been in post_content!

The same is true when some boneheaded plugin developer decides to store PHP serialized data in meta fields. (Carbon Fields did that in version 1.0, but thankfully fixed it in 2.0. The project I worked on included in-part moving or version 1.0 to 2.0 )

I really hope to see that all fields have an option for storing in post meta and that really good inline wizard explains to
walks the user through selecting the proper storage method.