The web is mostly a wall of text, dressed up
Most of the web looks like a wall of text with some CSS on top. The HTML underneath carries a little structure: paragraph, emphasis, list. The CSS adds visual style. A naive program reading the page might not know that the bolded phrase two paragraphs up was a book title, because the document never said so. The author meant it. The format didn't say it.
People have been complaining about this for a quarter of a century. The 1999 dream of the Semantic Web was that machines could read web pages the way humans can, and then act on what they find. The plumbing for that dream exists. Schema.org catalogs every kind of thing you might want to describe. RDF and JSON-LD give you formats to describe them in. The standards are stable and the tooling works.
The standards are also a pain to use. The author writes a blog post, hits publish, walks away. Adding structured data to that post is homework, and homework nobody asked for. So almost nobody does it. That is why, twenty-six years after the vision, almost no public web page carries the markup the vision required.
A different bet: the block as the API
The block protocol's idea is to make the right thing the easy thing. An author writing a post inserts a block, not because they want to add structured data, but because the block does the work of looking up the book, the address, the recipe, the person, and rendering it nicely. The structured data is a side effect. The author gets a beautiful block. The web gets machine-readable data. The cost of adding semantic markup goes from positive to zero, possibly negative, because the block saved the author a search-and-paste step.
This is the only bet worth making. People will only add semantic markup to their web pages if doing so is easier than not. If the cost of doing the right thing is higher than the cost of doing nothing, nothing wins, every time, even when the right thing is technically superior.
The WordPress wedge
A protocol without an editor is a spec. An editor without a community is a product. The block protocol needs both, and the easiest way to get both at once is to ship on top of the editor with the largest installed base on the open web. That editor is WordPress.
The WordPress plugin the team is shipping lets a user drop a block-protocol block into a WordPress post the same way they would drop a built-in block. The block renders natively, carries the structured data behind the scenes, and works without any knowledge of the underlying protocol. A developer who wants to publish a block writes it once against the spec and inherits the entire WordPress ecosystem on day one.
What changes if this works
If the block protocol gains traction, the open web starts to look more like the web the 1990s optimists imagined. Search engines get richer data without having to crawl and infer. Browsers can offer to call a self-driving car when they see an address block, or order a copy of a book when they see a book block. AI assistants that read web pages get something better to read than a styled-up wall of text.
The version 0.3 spec ships in February. The plugin ships in February. The hard part is what happens after: whether the developer community decides that a block built once for the protocol is worth more than a block built five times for five editors. That call is up to the people shipping blocks, not the people shipping the spec.