You've already started to add new things, like a TOTP-ish element, to stymie replays. Then the server has to check what it's been fed, having stored neither the original password nor the hash of the password it's been passed. It cannot be allowed to have the hash because the has is now the password. It need something safe-ish to store that the input can be computed on to make comparisons possible.
Now you have all the problems of server-side hashing and comparison coupled with extra client-side hoops.
Again, what have you gained?
> Do you realize that if an adversary even only has read access to the SSL layer, they can just copy the cookie and steal the account that way?
You are absolutely correct. That is completely accurate in every single possible way.
Do you think that perhaps there might be other reasons to consider here? Such as debugging, logging systems, and so on? Perhaps there are design goals beyond blocking direct attacks. On an average day, most of these systems will be more likely to be accessed and used by authorized administrators than by external adversaries, after all. Many security incidents arise not out of malice, but out of tools behaving dangerously. I know I've dealt with sensitive material leaking into logs.
I hope I have made myself clearer. I can see I failed to communicate effectively previously. Please, don't hesitate to say so if I have failed either there or in understanding your points.