People keep saying this, like too much effort is a bad thing. But OP makes it clear that there's very little duplication of effort in the Linux-on-phone/mobile/SBC community - most developments are shared community-wide. There are some technical divergences (Alpine/musl vs. glibc- and init-based systems for example) that can impact direct compatibility, but they're very minor.
they "sell" it as "25x duplicated effort" but in reality, there's 25x little tweaks to a build system, that give thousands of people zero effort to port their known platform right away. Now those thousands of people will have REAL effort to adapt their knowledge and existing ways to fit that one holy way enforced by the device true owners.
In reality it is "25x places where i will have to hide my plan for monetize this". Just like most other projects, greed always destroy everything the community help build in good will.
This is not a zero sum game: I believe we can have both an OSS approach to Linux while at the same time having a channel of commercial development that brings more adoption (and fun, hackable devices!). This "one holy way" and the multitude of community-based distros can coexist, in the same way that commercial software companies and OSS communities have already learned to.
These issues crop up on bleeding-edge hardware due to different distros running differently-timed versions of the same underlying components. They fade away over time as software versions start supporting the formerly-bleeding-edge hardware across the board, and the issues invariably shift to the next bleeding-edge hardware release. This is not an immutable fact about the ecosystem, it's a consequence of wanting something to function before it's fully ready for serious use.
* OS 1 finds a bug in Gnome, reports it and perhaps fixes it
* OS 2 benefits from pulling in the new code as well, fixing bugs
* OS 3 writes a driver for the camera and publishes it as part of their kernel
* OS 4 finds a bug in the camera driver they started using, publishes their fix
Yes, there's some overheard to running 25 projects. There's also a huge downfall to excluding 24 projects from contributing as first class members of the project. To boot, it's also a situation where the more contributions make the fixes contributed even more battle tested and beneficial.
tl;dr - OSS development styles don't map onto commercial development styles cleanly
Commercial development allows you to afford to control the hardware, make deals with other companies, and pay people to build compatibility with your system (i.e. Nvidia), which is what Microsoft and Apple did to keep their position. Server distros like Debian, Ubuntu, and Redhat already have deep foundational and corporate backing, and are a joy to use.
There are definitely drawbacks such as vendor lock-in and all the issues that come with corporate vs community control of the software. However, I believe having a single center of development and revenue (to pay for the development), while at the same time having fully open source software and hardware is possible and would have a huge impact.
Improvements and advancements would stagnate due to the 25x duplicated effort, and resources would be lost in keeping those projects happy. Also, any potential user looking to switch would be deluged with options, which is what crippled desktop Linux.
While I do not understand enough about Pine to know why they specifically made the business decision to gut their dev community and go with Manjaro Linux, my guess would be something along the lines of Manjaro's widespread dominance as a top Linux distro backed by a powerful foundation. Pine is pivoting to what they have decided is their future: a full-stack hardware to software open source offering that in their eyes would have a better shot at cracking open the phone market.
They probably were aware of the consequences, but have bet on making it big and creating a new, streamlined ecosystem after extinguishing this one. It remains to be seen if they will succeed.