Dynamic hash tables

What is the point of having an allocated table that is only partly used?

When you shrink that table by merging the last element with its "parent", but keep the same original table, you are occupying the same total amount of storage space, while slowing down access to one of the buckets. There is zero benefit here to offset that occasional slowdown. (Reduced memory usage from shrinking the bucket table size is the *only* benefit of reducing the number of buckets and you throw that away if you keep unused slots in the table.)

Splitting all of the buckets ensures that you split the longest/worst one(s) rather than simply splitting the last one (which might be one of the smallest buckets).

A dynamic split that can split buckets other than the last one have their own cost. The simple hash-index-listsearch becomes hash-index-maybeanotherindex-listsearch which is a small cost (extra code and time to determine whether this is a dynamically split list) that offsets somewhat the shorter list traversals. (Taken to an extreme, you would have a binary tree, with each node being either a tree node that takes the next bit from the has and chooses the appropriate sub-tree or an element node that is either the desired value or the desired value is not in the hash. But at that extreme, it has switched from an O(1) table index to an O(log n) series of tree traversals. That can be balanced by having each tree node use a variable number of hash bits to get back to O(1) behaviour.