The communication protocol must be secure. If the communication channel is insecure then the authentication is insecure. TLS/SSL is one way to secure the communication protocol. If you don't use TLS/SSL you would need to build a framework to build a secure communication protocol over an insecure link. If done properly (authentication of server, authentication of client, secure key exchange, encryption, message authentication, robust handling of downgrades, etc) the protocol would be complex. For all practical purposes you would just end up reinventing TLS/SSL.
So as written only #4 and #5 are secure and for most applications #4 should be the primary choice. This isn't to say you must always use #4 but you should be able to clearly articulate why in this scenario #4 is inferior to an alternative.
Zero Knowledge (deniability)
A variant of #5 can be useful in niche applications where zero knowledge or deniability is a core design requirement. Understand that is adds additional complexity so if you don't need deniability you are building a more complex system without improving security. Higher complexity means higher cost and greater possibility of introducing weaknesses which can be exploited.
An example of where zero knowledge authentication would be useful would be an online backup service. If the server has the encryption keys the service can be forced to reveal them (potentially covertly and without due process). If the server never has the encryption keys then they can't be forced to reveal what they don't know.
The raw file encryption is pretty straightforward. The encryption key is generated from the user's password by using a KDF. Files are encrypted client side and transmitted to the server. The server never has the user's password or encryption key. The challenge is how to authenticate the user (for verifying account status, billing, allowing uploads, etc). The default process of the user sending the password (#4) defeats the client side encrypting of data. So the site could have the user take the password hash it client side and supply that to the server. The hash should be produced differently from the encryption key (same kdf but different number of rounds or same password but a static prefix). One improvement over what you laid out would be that the server doesn't have to store the user's authentication hash directly. The server can store a hash of the hash which would prevent false authentication even if the password list is compromised.
Asymmetric Cryptography for Authentication
An option not listed would be to use an client side certificate to authenticate the client. The cert creation, management and secure storage/backup needs to be done completely client side or there is no point. The private key can be encrypted with client side password for additional security. TLS/SSL supports client side certificates so if this is a design requirement I would start there rather than reinvent the wheel. One advantage of ECC over RSA is it is more friendly to low powered and memory constrained devices like smartcards so this is becoming a more realistic solution although user education is still a challenge.