Not having third-party Snap servers is unfortunate, and something we probably should be forking Snap to add support for. Still, calling it "not freedom respecting" seems a little hyperbolic given that the actual part that runs on your computer is very much FOSS. It's not any different from, say, reading a website whose server software is unreleased, but whose client-side JS is all Free Software.
As for sideloading... yes, I want it too. But the only thing that really gives me is the ability to run some emulation and virtualization tools Apple refuses to sign for reasons ranging from unfortunate to stupid. Epic Games did not sue Apple for my right to run old Nintendo games on my iPad. In fact, the videogame industry has been very explicit that users should not be allowed under any circumstances to format-shift games they own, and Epic has done nothing to indicate that they are less consumer-hostile than their peers. They also said they'd accept a two-tiered system where they got their Epic App Store but users still couldn't sideload. So, as much as Tim Sweeney is ideologically motivated to support user freedoms, Epic Games is still pushing their lawsuit from the perspective of a proprietary software vendor, just one that's willing to go rogue.
You're right about RMS not being on the "same side" as Apple, and I misspoke. It's more like this is a three-sided fight between users (FSF, EFF, etc), proprietary developers (Epic), and platforms (Apple/Google). My point is that if you are extremely opposed to proprietary software in any form and for any reason whatsoever, then Apple's argument against sideloading is actually more reasonable, because it's the enemy eating itself. However, if you are at least slightly tolerant of proprietary software, then the argument Epic makes of Apple being anticompetitive makes a lot more sense.
I'm still not convinced that Apple's end goal is to make the Mac just be an iPad with a mouse and keyboard. The whole owner override thing I mentioned above took a lot of time and effort, just so they could boil the secure boot frog less. It would have been far easier for them to just say "no, we're only allowing macOS to live in EL2". Nobody was expecting them to allow this, and Hector Martin still has to occasionally field questions of "why are you working on this when Apple is just going to block it" when they haven't for several years now. Furthermore, Apple's designer brainworms have insisted upon not converging their platforms in any way that would make having the same security policy make sense.
>Aside from that, Mrs. Lincoln, how did you enjoy the play?
There really isn't another way to implement this while providing the same security guarantees for Free operating systems. The part that actually checks to make sure the code you're running was owner-signed needs to be both immutable from the perspective of malware and updatable in case of security bugs. You don't want this burned into a ROM chip since it's extra attack surface, even though that technically satisfies some weird exception the FSF made decades ago for the proprietary ROM BIOS in IBM-compatibles.
The only complaint I have about the way Apple did this is that they really should Free their boot chain code and have verifiable builds for it. However, there are very few, if any machines that actually have a Free boot chain. And the only harm a proprietary boot chain can do to Free Software is to refuse to load a Free OS. So as long as the boot chain allows us to do that, the crusade for a Free BIOS seems more of an academic or research concern than anything else.
[0] You're supposed to be able to enroll new secure boot keys, but AFAIK this isn't really ever done.