Splay tree
No metadata — and surprising amortised guarantees.
A splay tree carries no balance metadata at all. Every operation rotates the accessed node to the root via a sequence of "splay" steps. Sleator and Tarjan proved that any sequence of m operations on a tree of size n takes O((m + n) log n): same amortised bound as red-black, with much simpler code.
Search, insert, and delete each splay the touched node to the root. The splay operation uses three rotation patterns (zig, zig-zig, zig-zag). Cache locality is excellent because frequently-accessed nodes drift toward the root, and the tree adapts to skewed access patterns automatically.
Compilers (symbol tables for variable lookups in long-lived sessions). Some kernel structures. Linux's VFS dentry cache uses a splay-tree-like adaptive structure.
Worst-case single operation can be O(n). Don't use splay trees in latency-bounded contexts; use them when access patterns are skewed and amortised cost is what matters.