How is it possible for Hash Index not to be faster than Btree for equality lookups?
Disk based Btree indexes truly are O(log N), but that is pretty much irrelevant for disk arrays that fit in this solar system.  Due to caching, they are mostly O(1) with a very large constant plus O((log N)-1) with a small constant.  Formally, that is the same thing as O(log N), because constants don't matter in big O notation.  But they do matter in reality.

Much of the slow down in hash index lookups came from the need to protect against corruption or deadlocks caused by hash-table resizing concurrent with the lookups.  Until recent versions (every version you mention is comically out of date), this need led to even higher constants and to rather poor concurrency.  Vastly more man hours went into the optimization of BTree concurrency than hash concurrency.