I think you're asking a perfectly valid question. IMHO authentication is still an enormous mess and new standards like OAuth did nothing to improve it on the server side.
On your phone app store there's a strong and trusted source of identity coming from Apple or Google. They know who you are, what you're allowed to do, etc. and can delegate that authority to your apps.
On the server though... welcome to the wild west. How does your server know the person on the other end of a TCP connection is really you, or the person you shared a document to view, etc? You can put your trust in a third party authority like Google, Facebook, Auth0, Okta, etc. but that usually comes with a financial cost. You can roll your own auth or self-host an auth server, but then you're taking on a huge security burden and it's a big leap in complexity to manage something like Keycloak, an LDAP server, etc. It's just not an easy problem to solve with the tools the web gives us today.
It seems to me you are making it needlessly complicated (LDAP...). There are many tools for authenticated access to server with minimal cost in terms of administration. TLS+Letsencrypt+Basic HTTP auth, SSH, OpenVPN, Wireguard, etc.
If you’re using N+1 servers that have multiple users, then you definitely want some kind of centralized user management. It doesn’t matter how you connect to the server (ssh, etc). Those won’t solve the problem of keeping user account information in sync between the servers. You still need some way to keep account information (username, password, public keys) consistent between the servers.
That’s what the GP post was comparing to.
I use LDAP to manage access to multiple servers and it’s more work to setup than /etc/passwd, but much easier to keep things in sync.
On your phone app store there's a strong and trusted source of identity coming from Apple or Google. They know who you are, what you're allowed to do, etc. and can delegate that authority to your apps.
On the server though... welcome to the wild west. How does your server know the person on the other end of a TCP connection is really you, or the person you shared a document to view, etc? You can put your trust in a third party authority like Google, Facebook, Auth0, Okta, etc. but that usually comes with a financial cost. You can roll your own auth or self-host an auth server, but then you're taking on a huge security burden and it's a big leap in complexity to manage something like Keycloak, an LDAP server, etc. It's just not an easy problem to solve with the tools the web gives us today.