These changes are engineered to give consumers more privacy and security over their invaluable email communications. Only Apple can do this.
Not really — at least not in this case.
Mail plug-ins were so convoluted to install and maintain that most average users would never have bothered. Even on this thread, many didn't know the capability even
existed, much less how to use it. From the beginning, Mail plug-ins/bundles were more of a power-user tool; IIRC, the capability first showed up in 2004 when Apple introduced a massive update to the Mail app in OS X Tiger, and it's been just sort of kicking around ever since.
However, the problem is that Apple never "officially" supported these plug-ins. The Mac was in a different place back then — everything was more grassroots in those days — and Apple's developers were happy to provide a plug-in architecture for hobbyists to play around with at their own risk. If your plug-in broke something, that was on you, and Apple never guaranteed that its code for these plug-ins would remain consistent — if Apple broke something in a Mail update, it was the responsibility of the developer to figure out what had changed and fix their plug-in, with no official help from Apple.
In fact, the risk of things breaking was so high that Apple coded in a "compatibility UUID" in Mail, changing it with each update. At the very least, plug-ins had to be updated with the new UUID for each new version of Mail; Mail would refuse to load any plug-ins that didn't have a matching UUID.
For simpler plug-ins like Gmailinator, it was usually enough to just dig out the new UUID from Mail.app's Info.plist file and paste it into Gmailinator's. The code-signing requirements in more recent versions of macOS made this a bit more complicated, but it was still doable. I usually just rebuilt from source in Xcode with each new macOS point release and dropped in the newly-compiled bundle with the proper UUID. Actual code changes were usually unnecessary as Gmailinator didn't do much other than remap a few keys.
More complicated plug-ins like Smallcubed's Mailsuite were also usually fine with minor point releases, and the developers typically pushed out the necessary versions quickly enough to ensure the UUIDs matched. Major macOS releases required bigger changes, which was why Smallcubed eventually began selling paid upgrades and maintenance plans as they had to put actual work into it, and it wasn't as simple as following Apple's documentation on what had changed
because there wasn't any. Instead, they had to figure it out for themselves.
So, all that having been said, Apple's motivation for removing this is most likely some software engineer who has become exhausted with maintaining a massive chunk of legacy code that's nearly 20 years old. They've likely been keeping it together with bandaids and bailing-wire for years, as it was never an official feature of Mail in the first place. Who knows, maybe the folks who originally built it, maintained it, and championed it aren't even at Apple anymore.
On the flip side, removing the plug-in capability will also encourage developers who
can use the new MailKit extensions to get with the program and rebuild them for the new features. They've had two years to do this,
but it's a lot of work, so staying with the plug-in model has just been way easier. It seems some will be able to move to extensions, but sadly the limited MailKit frameworks will be leaving a lot of other great ones behind.