In MySQL, an index type is a b-tree, and access an element in a b-tree is in logarithmic amortized time
you can only access elements by their primary key in a hashtable. this is faster than with a tree algorithm ( O(1) instead of log(n)) you cannot select ranges (everything in between x and y). tree algorithms support this in Log(n) where as a hash index can result in a full table scan O(n). also the constant overhead of hash indexes is usually bigger (which is no factor in theta notation, but it still exists). also tree algorithms are usually easier to maintain, grow with data, scale, etc.
hash indexes work with pre defined hash sizes. so you end up with some "buckets" where the objects are stored in. theese objects are looped over again to really find the right one inside this partition.
so if you have small sizes you have a lot of overhead for small elements, big sizes result in further scanning.
todays hash tables algorithms usually scale. but scaling can be inefficient. there are indeed scalable hashing algorithms (don't ask me how that works - its a mistery to me too. afaik they evolved from scalable replication where re hashing is not easy. its called RUSH - replication ander scalable hashing, and those algorithms are thus called RUSH algorithms).
however there may be a point where your index exceeds a tolerable size compared to your hash sizes and your entire index needs to be re build. usually this is not a problem. but for huge, huge, huge databases, this can take days.
the trade off for tree algorithms is small and they are suitable for almost every use case and thus are default.
however if you have a very precise use case and you know exactly what and only what is going to be needed, you can take advantage of hashing indexes.