B-trees are used because they are a well-understood algorithm that provides the “ideal” cost of reading in sorted order. Since the keys are sorted, moving to the next or previous key is very cheap.
HAMT, or another hash store, stores keys randomly. Keys are retrieved by their exact value, and there is no effective way to find the next or previous key.
As for the degree, it is usually chosen indirectly by choosing the page size. HAMTs are most often used in memory with page sizes for cache lines, and btrees are most often used with secondary storage, where page sizes are associated with I / O and VM parameters.
Log Structured Merge (LSM) is a different approach to a sorted order store that provides more optimal recording performance when trading with some reading efficiency. This hit on read performance can be a problem for read-modify-write workloads, but the fewer unreadable reads there are, the more LSM provides better overall throughput versus btree - at the level of higher worst read latency.
LSM also offers the promise of wider use of the envelope. Entering new data into the proper place is “postponed”, offering the opportunity to tune read / write performance by controlling the proportion of deferred cleaning work for live work. Theoretically, an ideal LSM with zero deferral is btree and with a 100% deferral is log.
However, LSM is more a "family" of algorithms than a specific algorithm such as btree. Their use is growing in popularity, but it is hindered by the lack of a de facto optimal LSM design. LevelDB / RocksDB is one of the most practical implementations of LSM, but it is far from optimal.
Another approach to achieving write throughput efficiency is to optimize btrees with snooze when trying to maintain optimal throughput.
Fractal trees, shuttle trees, layered trees are a type of design and represent a hybrid gray space between btree and LSM. Instead of deferring recording to a standalone process, they cushion write-deferal in a fixed way. For example, such a design may be a fixed fraction with a delay of 60%. This means that they cannot achieve 100% LSM write performance, but they also have more predictable read performance, which makes them more practical replacements for btrees. (As in commercial projects of Tokutk MySQL and MongoDB for fractal trees)