But this is of course even worse because most servers log this. Headers are not often logged.

  var __currentForum = 
  window.CommuntiyForums&&CommuntiyForums.findCommuntiyHomepageByUrlPath()||'';
            if(__currentForum&&__currentForum.hit){
                lmdBrandVal = "Forum Details:"+ __currentForum.forum.board;
            }else{
                var __websiteInfo = sessionStorage&&sessionStorage.websiteInfo ? sessionStorage.websiteInfo : sessionStorage.currentCommuntiySite;
                if(__websiteInfo&&JSON.parse(__websiteInfo).board) {
                    lmdBrandVal = "Forum Details:" + JSON.parse(__websiteInfo).board;
                }
            }

Ever had Google deny you access for a perfectly valid username/password combo when loging in from "unfamiliar" location? :) Or a bank ask you for SMS code when logging in from a different browser?

It really depends on level of paranoia of the authentication system. You can have user device validation even with username/password, and you may not have it for session IDs in a different implementation.

Usually, a responsible website will password-hash the plain-text password into a hashed string before saving the hashed string into their storage. Password-hash is a special hashing process designed to be reasonability slow, so an attacker who somehow obtained the hashed string cannot easily collide the hash with another plain-text.

Some password-hash configuration can took few milliseconds to run, that's really expensive if you have to do that for every request just so you can compare the client password-hash v.s. the one stored on your server.

(Full disclosure, I designed few session manage systems for my job before :D)

I can selectively deauth a user to make them login again in short order and take his password.

It depends on the level of compromise, of course.

Return a 401 on the "logout" page?

Not if they're HttpOnly cookies. Then it requires actually compromise/mitm of the application server code to recover the cookies.