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.