I think that it's a vulnerability in browser. It was surprise for me, that it's possible to issue POST requests to some completely unrelated website just because dns changed its IP. 127.0.0.1 is one example, but I'm sure that there are billions websites which process POST requests for important actions and their webserver doesn't check "Server:" header. This attack just circumvents origin policy, it's definitely a browser bug.

Well, it's all relative to the threat model. It makes some sense on a single-user machine where you don't run any untrusted code, as the same user or not.

On a single-user machine, an attack scenario where authenticating localhost would actually do some good would be some other account existing that's easier to break into than the account of the user actually doing stuff. But if no other login exists?

It should be noted that a desktop is not a single user machine, even though there may only be one human user operating the machine. A single user machine is a machine running in runlevel 1 -- in other words every process on the machine is running as one user and you cannot switch users.

Modern desktops do not run at runlevel 1. All sorts of services and daemons run under different users, so having an unauthenticated service listening on localhost is less secure even on a desktop machine. If you have network services running on a desktop machine (common) then a simple RCE in an unprivileged user (with respect to the human user) can result in wallet compromise. If the API was authenticated that would not be possible.

Unix DAC protects users from one another, so any service which exposes personal information outside of the currently running user has objectively inferior security to a security model invented in the 1960s.

I can see where you might set things up like that on a single-user machine after careful consideration of everything that's running on it. But making that the default seems like madness.