The way supported add-ons work right now is that there's a list (AKA a collection) of supported add-ons maintained by Mozilla that you see on a phone by default.
They allow direct installs of add-ons that they know were tested properly and work fine on a phone, not those where they can't guarantee that level of stability (while still giving you that as an option if you feel like experimenting).
I don't see how that's arbitrary, I see it as a well thought out process, even if I wish more add-ons were added to that collection.
I agree that there should be more allowed add-ons. Engineering didn't put in all the effort to implement the add-ons APIs on Mobile only for it to be restricted to such a small set. Unfortunately that's a product decision.
> he way supported add-ons work right now is that there's a list (AKA a collection) of supported add-ons maintained by Mozilla that you see on a phone by default.
They're not maintained by Mozilla, but they're "recommended" and are reviewed more thoroughly.
Unfortunately it seems that at some point they've also talked themselves into believing that continuing to run add-ons within the main browser process has suddenly become the height of irresponsibility and absolutely and totally unsafe, so a few add-ons are grudgingly permitted with additional scrutiny given during review, but
- they don't want expand that process further, because it's counter to the direction that AMO has been moving (from manual pre-publication review of all public add-ons towards automated checks and only manual post-publication spot checks)
- running add-ons in a separate process as on Desktop isn't possible, because on Android secondary processes can get killed at any time, which add-ons aren't set up to handle correctly
For some reason I've only seen this explanation buried somewhere inside some Mozilla's Discourse forum (I think, if I remember correctly), but I think not much (if at all) as an explanation in the Github issue tracker and certainly never on the official Add-ons blog.
Though I have to admit that even if the above explanation was given a wider airing, for me it already smacks too much of "the safest computer is one you never turn on" and I'd still be unhappy about the add-ons situation and continue complaining.
> running add-ons in a separate process as on Desktop isn't possible, because on Android secondary processes can get killed at any time, which add-ons aren't set up to handle correctly
That's true (though it will probably improve as WebExtensions evolves toward service workers), but engineering wasn't hung up on that.
On the engineering side, there aren't any good reasons. Engineering didn't put in all the effort to implement the add-ons APIs on Mobile only for it to be restricted to such a small set. It's product management's decision.
You can create a custom collection on a desktop and then override that Mozilla's collection within mobile Firefox's settings: https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...
You can install any add-on available on the desktop like that, but your mileage may vary of course.