We know balanced trees perform insertion, deletion, and search in O(log n)-time, examples include
One of the reason is that complexity is defined not on the size of the set you store but on the size of the universe of values. Another difference is that keys can't be arbitrary types for which you have comparison operation but must be integers. You should not see vEB as an alternative for BST but rather as an alternative for arrays. An array have O(1) store and look up costs for object keyed by integers. vEB offer O(log log M), where M is size of the universe of your values. Now, you see vEB is not better than regular array for look ups and store but it offers O(1) min, max operations and O(log log M) prev next key operations which array does not. It's worth to mention that the layout of vEB trees has a properties which make possible to create cache oblivious trees which are far more interesting developments of modern CS.
http://erikdemaine.org/papers/BRICS2002/paper.pdf
The asymptotic complexity is sometimes misleading. In the case for Van Emde Boas tree
the constant is quite large see here. I quote:
However, for small trees the overhead associated with vEB trees
is enormous: on the order of 2^(m/2)
There are also other cases where an algorithm with better complexity exists but it only gets better for an input so big that in practice it is almost never used e.g. linear time static RMQ.