I think UBPorts and Sailfish prove that Linux for phones is practical if you're willing to rely on Linux applications that stick to mobile friendly APIs.
You need to configure and compile your Linux kernel for aggressive power saving, of course. Seeing how Linux currently struggles to effectively do power management on laptops without S3 sleep, there's plenty of work to be done if you want to use it with a phone.
It's not just about app developers either, Qualcomm's modifications to the Linux kernel are public thanks to GPL but most phone kernel modifications haven't made it into the upstream kernel so far. Projects like postmarketOS are trying to make things better but it's not easy to port practical code that works into code that's acceptable for the maintainers of the broader Linux project.
Hell, my watch runs Tizen and that's running a bog standard Wayland + PulseAudio + systemd setup: https://docs.tizen.org/platform/porting/system/#systemd
With the right kernel drivers, configuration, and tweaks, with a well-configured userland on top of that, you can run the "normal" Linux stack in a mobile device.
Getting applications to conform with an API that won't let them drain the battery in the background to make sure notifications don't arrive two seconds too late is much harder. Desktop applications don't really like being suspended/resumed the way mobile applications do.
Are there well-known good practices?... Or, do they need to be rediscovered as they are perhaps proprietary know-how?
It's a model that worked fine in multi-user setups where you ran a single executable, so that the security per user was meaningful, but today it just sucks.
Android is quite elegant in reusing the Linux kernel's permission system, but on a granularity that actually makes sense (apps are started as separate users, and they just elevated their concept of user a level higher).
Will you be happy with xeyes and a terminal? Like, even a technically superior solution is completely useless without an ecosystem to make use of it, and desktop GTK/qt apps won't work nicely on mobile without actual porting. Let alone a technically significantly inferior one that is a misfit in this shape for mobile hardware.
Mobile apps just had to "grow up" in this environment, plus they have proper APIs for this two-way communication between OS and the app. Android will just ask the app to save its state and then simply unload it from memory (after a while) - but this also makes perfect sense for the desktop scene, you also want to improve energy efficiency there. A spreadsheet app doesn't have to continuously run when it's in the background. You just have to add proper APIs and permissions so that apps can optionally ask for extra background work.