There are some problems and also some development in this area.
System & Apps
Problem: Desktop Gnu+Linux uses a monolithic x86_64 kernel most of the time. All apps are installed on the system with no separation, every system is unique and users have root access to fix it themselves.
Android is immutable and atomic, with a single upstream system that ends up on all devices. This system can be checked, verified, verified boot etc. This of course doesnt work if everyone uses a different set of packages.
Immutable Linux Distros are there to help, and image-based ones like Fedora Atomic, the new VanillaOS, SteamOS and a few more all imitate Android here.
Android App security model
The problem is, that Android started as a mobile OS, using the Linux kernel, but having a lot of integrated working apps from the same origin. Like GNOME and KDE apps often follow modern standards, Youtube, Google Play etc. could instantly work on their new, restricted App model.
This app model means
- every app runs in a sandbox
- all apps start with (near) 0 permissions, they can only read/write in their internal storage, everything else needs manual allowance by the user. (GrapheneOS completes this sandbox with more permissions, Internet, Sensors, inter-process-communication coming soon)
- everything a user installs keeps the system untouched.
Meanwhile the OS is updated automatically, changed and tested upstream for every individual device and the user doesnt need to, and also can't change anything normally.
While the OS is pretty standardized, the used Linux Kernel is highly specific, slimmed down and integrating sometimes proprietary platform drivers so that it runs on that specific device.
Desktop is chaotic
Meanwhile desktop linux has everything manual, traditionally. Apps are installed to the system, users can remove everything and apps can read/write everything, there is no permission model.
Desktop platforms in general are still way less secure than Android, because they are older and didnt dictate secure requirements BEFORE the applications where developed for them.
Immutable Linux Distros
Modern Linux Distro models can have a system that you dont need to change. This is still not verified etc. like Android, but it is read-only and could be verified, for example by using something similar as ChromeOS.
On these Distros you can install all apps from Flathub, which has a permission system more fine grained than Androids in some cases (IPC and network for example are already there), but it is not enforced.
Tons of apps need to adapt to this system and developers dont care. Android is a pain in many cases because it is so secure. Try to use configurations across multiple apps, or copy files between two mounted drives.
Developers would need to adapt to something similar than that, and it is not nearly done yet. In the meantime I maintain a list of flatpak apps following these modern standards, those apps use Portals, dont access your mic when you dont know it, dont access files etc. Not all of them are checked, tbh most apps have at least one missing.
This is only the distribution and packaging model.
Kernel
Then the problem with "Linux phones" (i.e. porting the mainline Linux kernel + Desktop stack to android phones) is that you need to patch the kernel.
As mentioned, that kernel is slimmed down (it doesnt run on a Toaster) and has additional drivers integrated.
The problem with "postmarketOS" here is, that they would need to have access to all the changes that the manifacturer did to Linux, and apply those quickly, to an updated kernel.
GrapheneOS does this but also only for the official lifespan of the official Android, where they get all that "hardware porting" work from. Doing that on your own is intense work.
This means postmarketOS will likely use an outdated kernel, which is not acceptable really.
libraries, userspace etc.
Then the next thing is all the rest. Android uses bionic, desktop Linux uses glibc, which is full of security issues. PostmarketOS and AlpineLinux use musl, which is hardened and minimal. The problem is, that every app needs to be compiled to run with musl, instead of glibc.
This means you need to use alpines package repos, flatpaks will likely not work. A security degradation because Desktop Linux is so fractured.
I am not at all an expert, but this will be the same for many other things that are more complex, not standardized and less streamlined on Desktop Linux as on Android.
RAM consumption
The goal of Flatpaks is "make every app run on every distro". There are others, like a reasonable sandboxing model (but with "have all apps work" as first priority, unlike Android).
But as Flatpaks use seperate runtimes, and Desktop Linux cannot run completely on Flatpak, this is somewhat flawed. On phones you may have little RAM, as the system uses libraries and Flatpak apps use others. On BTRFS filesystems (highly recommended, no ext4 is not the best and only) deduplication reduces storage space but still, it is worse than on Android where all apps share libraries (as far as I understand).
other optimizations
Also all the rest of the OS is not tailored for minimal load. Battery life on energy saver is horrible, and there is no "screen off, automatically use snooze processes".
Also things like optimization for cell networks, safe data, LTE-only, network location, A-GPS, no idea how well those work.
Have a look at secureblue which is kinda the best we currently have. It is hacky, Alpine may be a better base than Fedora, Flatpak may be flawed as they are very traditional regarding hardened runtimes.
Some cross-platform apps will use Electron which is a security issue (at least compared to Chromium, and patches may be delayed because of duplication).
QubesOS is an overcomplex solution for the current problem, as there are no well working established permission models. If you need some of the advanced protection, I suppose it is still needed. But a good Flatpak+Bubblejail system with a hardened kernel should also work.
I am very interested in trying to build a mobile OS based on secureblue/some immutable alpine, using a custom tailored kernel. But all the mentioned issues will cause problems, and it would only be experimental, as on supported phones, GrapheneOS is "just enough" and most secure, and unsupported phoned will not receive firmware updates, and manually patching a kernel is far beyond my knowledge.