I don’t have any benchmarks at hand, but I’ve been years running containers in production and in every case the performance has been exactly the same.
Well I’d consider this a feature.
Depending on the service type, it may or may not be interesting to share disk with others.
For example, for services like Syncthing and Nextcloud it would make a lot of sense to be able to share a mount. However for services like Synapse and Gitlab it would be absurd.
Yunohost could easily then decide that its default data goes into /var/lib/yunohost. Then the pro user could just mount a device there and know all data is in a known place. Or Yunohost could have a nice UI setting asking the vanilla user where to store data, so he can just plug in an external disk and tell Yunohost to move all there.
It would make much easier to fix the Disk encryption problem, because all data would be in a single dir. It would also make much easier backups. And make yunohost more secure also.
Those examples you mentioned could be containers too indeed 
However I’m just saying that this one could be an additional packaging format, I’m not talking of just dumping all work and starting from scratch. That’d be crazy! At least for Yunohost.
The benefit of podman is that it mostly behaves as a normal Linux package. In docker you have more infrastructure and security issues to think about, but in podman you can just drop in a systemd unit file and know it works as expected. Your app is packaged in a container instead of a .deb, but it respects all the host inherent security systems.
The cost depends on how you face it.
If you just add it as an additional packaging option, then the process of deprecating the old system can take as long as you need. There should be no problem on both coexisting (I ignore the inner details of Yunohost packaging still, I’m just theorizing here).
The benefits:
- Every exact byte you test is going to be deployed to your users. No more lib conflicts, no more broken upgrades…
- Updates are atomic, per app.
- Can roll back.
- Very wide knowledge on this packaging format.
- Not tied to one distro. This can be a guideline or project requirement, but not a technical one.
- Previous point would help on upgrades. I see you’re still on debian 9 (which doesn’t run in my Raspi 4 BTW
). I’m just guessing here, but maybe the difference in debian 9/10 packages is delaying this update? The more apps you containerize, the more independent you become of the underlying host system, the faster you can get to support a new Debian version. - More secure: one vulnerable app could be secured more to not affect others.
- Configurable isolation.
First of all sorry if my thread seems to you like a “you’re doing it wrong”. It’s not my intention at all. I think you did a great job! I’m just asking to see how this could be improved.
This is probably one big problem. I’m facing it at work also, where some folks refuse to start using containers, no matter how simple you make them. They just don’t feel at home.
It is more a psychological aspect of these kind of changes than a technical one probably.
Of course you guys probably don’t have a lot of time to invest in changing the roots of a project. However, it’s also true that probably using a more modern technology stack would attract more young workers.
I’ve been wandering around a lot and Yunohost seems to be the best anti-GAFAM project available today.
I agree that sometimes it’s easier to start something new than migrate something old. Hard to balance indeed. 
If we abstract away the packaging and deployment system, there’s at least 2 things of Yunohost that could still be usable in that supposed future replacement project: its UI and its SSO. Are those pieces reusable outside of Yunohost? Any other piece I’m missing?