XTDB is a recent implementation of these ideas. In their docs they call it a bitemporal database, but it seems to match what is called a temporal database in the paper
It seems like sometimes what we want is the state at a point in time (eg. for rolling back the database of a managed networked embedded device).
Other times what we really want in these systems is state as of a point in time based on the current set of timestamped, (effectively) mutable facts.
Analytical systems are a different world where time seems to often be regarded as "just another dimension", but strong consistency and auditability are increasingly relevant there too, which is also a natural reflection of how a lot of modern OLAP systems operate internally using immutable snapshots of blob storage (see Snowflake, Iceberg, LakeFS etc.).
I know there are definitely lots of potential tricks for making better use of a first-class understanding of time in analytics though, and not just treating it the same as other dimensions, e.g. https://duckdb.org/2023/09/15/asof-joins-fuzzy-temporal-look... and https://materialize.com/blog/temporal-filters/
You're right, of course. We want both.
As it turns out, AsOf in SQL is a problem I ran into just yesterday when ensuring that serialized report snapshots point to the correct historical versions of their resources.