Here's the reason Article became a second class citizen...
In this issue I raised against Mastodon in 2017 (on a now defunct github account), Mastodon at the time treated Note and Article identically. In particular, it removed all the HTML except for 'a' tags - even from Article. This made federation with the elephant impossible for us. At this time the ActivityPub fediverse consisted of Hubzilla and Mastodon. Period. The specification wasn't even final yet. Hubzilla provides long-form multi-media content, just like a blog. This content was completely destroyed by Mastodon's HTML sanitizer, especially blockquotes, which displayed everything we quoted as original text and mis-attributed.
My proposal to the Mastodon team (which was basically Eugen) was to relax the input sanitisation on the Article type a bit , and Mastodon could have their plaintext Note and we could have our multi-media and the fediverse be one happy family. Regardless of the fact that HTML is specified as the default content-type for all content in ActivityPub.
The response from Eugen was to turn Article into a link, meaning our content wouldn't be shown inline at all - and closing the issue. I believe this is the last time I ever communicated with Eugen and I will never, ever file another issue against Mastodon.
We started using Note instead, so that our messages would federate at all and knowing that Article would have been the most sensible choice.
We also need to strip all the images out of our perfectly renderable content and add them back in as attachments - otherwise they won't be displayed on Mastodon. As it turns out, Mastodon only adds back 4 images and reverses the order. This is less than satisfactory because the source content lets us position text around each image, and it forces anybody with multi-media content to not only perform this unnecessary step, but also to check every attachment on import and see if it was already included in the HTML - or it will be displayed twice.
As far as I'm concerned, Mastodon should be taken to the mountain-top and cast into the volcano. But it appears we're stuck with the infernal thing.
You can make a protocol that allows for not-yet-defined behavior, or has parts that are prescribed to work in a certain way if you're choosing to implement some certain behavior although you're not required to. The 7-layer OSI model and SMTP-email headers are two good examples. Even grafting encrypted or multimedia email on top worked, more or less, reasonably well and was still interoperable for the most part. They could have used that type of thing as a starting point, instead of doing the equivalent of "well we don't want to constrain what types of networking applications you might want to implement, so we're just gonna specify the from and to addresses. You do your checksumming and MTU management the way YOUR application wants to do it."
I mean I'm not gonna sit too much in judgement of someone who created something which is working and producing good things but it's hard not to be wistful about how much better it could be if the spec was specific enough that the different apps could substantively talk to one another.