Putting the username and password fields together has other advantages than you mentioned. It means no additional requests (or JavaScripts or CSS) are required between entering the username and password, and it also makes it more difficult for attackers to guess usernames.

I would want to see X.509 client authentication used more often. It has many advantages, such as:

- Cookies and JavaScripts are not required.

- The credentials cannot be stolen. (With TOTP, the credentials can be stolen for one minute. I have been told that some implementations only allow thirty seconds, but that can cause problems with legitimate authentication if the clock is not precisely synchronized.)

- It does not require a web browser; it can also be used for command-line access as well (rather than using API keys, which are really just another kind of passwords, with the same problems).

- It is independent of HTTPS; it can be used with any protocol that uses TLS (which includes HTTPS but also others). Therefore you can authenticate with multiple protocols if wanted.

- The private key can be passworded for additional security, if desired. (This means that it can already be like a kind of 2FA, but on the client side instead of the server.) This password is never sent to the server.

- If permitted, the keys can be used to sign data which is distributed, allowing other receivers to verify it. This is true of using public/private keys in general, even without X.509. (If X.509 is used, the keys might or might not match those used with X.509, and this might be mentioned in extensions inside of the certificate.)

- They can be used to allow using credentials from one service to log in to a different service if the user intends to do so (and the service allows it, which it should not be required to do). No authentication server is needed for this, since the necessary information is included within the certificate itself. (The buttons to authenticate a variety of other sites, that you mention, also will be unnecessary.)

- Partial or full delegation of authorization is possible (if the service that you are authenticating with allows it). Each certificate in the chain can include an extension specifying the permissions, and the certificate chain can be verified that each each one has a (not necessarily proper) subset of the permissions granted to the issuer certificate.

- You could have an intermediate issuer certificate to fully delegate authorization to yourself (as mentioned above), where the corresponding issuer private key is stored on a separate computer that is not connected to the internet, in addition to being passworded, for additional security, if this is desirable. If the certificate that you are using to authenticate with the service is compromised, you can create a new one with a new key and revoke the old one.

- Some services may allow you to authenticate with any OpenID identity provider, including making up your own. X.509 is a better way to do something similar; if self-signed certificates are allowed, then anyone can make up their own, without requiring to set up an authentication server. OpenID also allows additional information to be optionally provided, and this is also possible with X.509 (without the additional information being limited to a fixed set of fields or being limited to Unicode). Also, OpenID requires a web browser but X.509 doesn't require a web browser.

- DER is a better format than JSON, in my opinion.

(However, I also think that TLS should not be mandatory for read-only access to public data. TLS should still be allowed for read-only public access though; it should not prohibit it. The use of X.509 client authentication means that you can't authenticate with unencrypted connections by accident, anyways.)

It would still be possible to support 2FA if this is desired because some users prefer it (and when doing so, it should do the things you mention, since they would avoid some of the problems with existing systems), but should not be required.