Crux timestamps sit outside of the data model and apply universally across the whole database (the data model is documents not tables), so you don't have to consciously think about managing bitemporality at all by default, but whenever you might need it, it's there. This means you don't have to adapt your queries to account for extra fields/columns, instead you just specify the timestamps of interest as simple parameters to the query datasource.

Also, Crux maintains a point-in-time (a.k.a timeslice) temporal index which is really a Z-Order Curve[0] that stores the two dimensions for fast lookups in a local KV store like RocksDB or LMDB. By contrast, a userland RDBMS implementation of bitemporality will be significantly slower to execute similar point-in-time "as-of" queries.

[0] https://en.m.wikipedia.org/wiki/Z-order_curve

(I work on Crux)

You can implement bitemporality on top of a database kernel not explicitly designed to support it but you sacrifice significant performance and scalability. It is a bit like trying to implement a graph database on top of a relational database -- it definitely works, just not well.

Database kernels designed for first-class bitemporality support have low-level internal structures to optimize operations on bitemporal data models not found in typical database kernels. These features are not free if they aren't being used, hence why they are relatively rare in databases that are not explicitly bitemporal.