Why does Micropub use a single endpoint that handles all operations? It seems like the kind of thing that would greatly benefit from RESTful API design, considering all of the operations you perform using it are against specific RESOURCES.

Create/update/delete operations should not all be handled by POST calls with a different "action" property (and only update/delete have the action property - create doesn't!). Why can I create resources using one of application/json, application/x-www-form-urlencoded, or multipart/form-data content-types, but if it's JSON then I have to check if it's a update/delete? Why not, I don't know, use the PUT and DELETE HTTP methods that are meant for this?
There is seemingly no read operation at all for programmatic access, that's left up to the implementation generating an HTML document that uses the Microformats2 h-* vocabularies, which Microformats2 implementations should just parse the HTML to read entities. What???

Speaking of Microformats2, the Micropub spec depends on it for the different types of resources you can create with it (cards, entries, citations, etc.), and defers to the Microformats2 wiki to explain all of that. The problem is that Microformats2 seems... incomplete? Not all documentation is there, and there's no clear place for you to start getting a grasp of all the concepts. You're just thrown right into it and left to figure it out. Which is not good, to say the least, for a purported specification. Specifications are meant to be complete, self-contained things with formal definition, not a vague list of properties with no validation rules at all.