There is a technical reason and a design reason for the current behaviour.
Firstly, snapd requires some form of authentication since it is performing a system-level operation. On the command line you can use sudo, just like when you
apt install, so no online account required. When using Software, the only form of authentication currently available is the Snap store. Alternatives are being discussed...
I did an attempt to resolve this by trying to get snapd to generate a Macaroon without store access. But as I understand it getting a Macaroon requires a round trip to the store.
So I think the solution to this is to either allow snapd to generate local Macaroons or use some other type of authentication token for local access. (comment 27)
Secondly, SSO authentication was the primary design pattern because Snappy's primary use-case is managing multiple IoT devices. The negative effect on desktop/laptop users was unplanned.
The net effect is much better security for these devices... look at modern wifi access points, for example. You get a single management
account, usually in the cloud, and you manage all devices through that. (comment 25)
It looks like there is a plan to change the behaviour so that desktop/laptop users aren't required to use an online account to authenticate. You can subscribe to the bug to receive news as changes are made.
Handing out a token to root that provides an authorization to manipulate the system is analogous to allowing root itself to be doing removals without further store information, which we allow... The necessary infrastructure for that is pretty much in place since we already have to maintain the local and remote macaroons separately, and the situation where the remote macaroon is missing or incorrect is already handled. (comment 29)