Unfortunately, your arguments may seem logical to someone unfamiliar with hashing. I'll explain the key flaws in your concerns:

1: Hash collisions Depending on your hashing algorithm, you'll have a hash length of 32, 40, 64 characters/digits (among other combinations). This can't possibly be unique for every single file of every possible length - it's mathematically impossible. That's not the intent of hashing, and that fact a cornerstone of understanding cryptography (and cryptographic weaknesses). So, no, it does not reduce the protection provided at all, unless you're one of the security through obscurity folk who is proposing that the hashing algorithm is kept secret from the clients. But please explain any scenarios where a compromise of the server and stored hashes would not result in a compromise of the hashing algorithm.

2: YES! Hashes are essentially the password for the user account. This is how all authentication that does not rely on a key exchange/handshake works. I'm glad you've realized this. In fact, this is a very old attack in some poorly designed systems that use handshakes (e.g.: Microsoft's NetNTLM https://en.wikipedia.org/wiki/Pass_the_hash).

3: You state: "Additionally, a compromised server could easily alter the hashing code to push out the original password file for sniffing anyway" I'm trying to make sure I haven't misinterpreted, so let me give this a shot. You're proposing that a hacker might modify the libraries used to perform the hashing process on the server in order to bypass the need to attempt doing offline attacks against the hashes it stores? Wasn't your argument that doing server side hashing is somehow safer? This statement of yours directly conflicts with that argument. I'll toss this one in here too - if a hacker controls the server, the much more direct route would be scraping the fields as they're populated (first way that comes to mind is to add javascript to the page) or, in this case, modify the file upload process to make a copy of the file.

In all cases, your final point is completely flawed - and is the fundamental reason that client side hashing is better for performance AND for security - "If the server can't be trusted, you can't trust anything else that's touched it either." You're right, so why would I want to give a server my actual password/passfile/authentication details instead of a one way hash of those files?