My interpretation is; Oxide already chose to use Clickhouse as their DB for metrics in it's rack. You can't just slap PromQL on Clickhouse because DSL's like PromQL reflect some of the inner workings of for example Prometheus. Hence they needed a DSL which was somewhat opinionated towards Clickhouse in order to make it work.
1.2 doesn't go into nearly enough detail to be convincing, in my opinion.
Personally I think this sentence summarizes the need pretty well: "Many telemetry systems have implemented their own DSL, and each tends to be tailored (intentionally or not) to the underlying data model and storage mechanisms.".
Also it's not like they've implemented a custom storage back-end, it's ClickHouse. ClickHouse itself thinks SQL is fine for querying time-series data (as do Snowflake and TimeScale, for that matter).
Ultimately of course Oxide can do what it wants, but the justifications provided in this doc are thin enough to make NIH seem like a very plausible explanation. Perhaps the problem domain is more complicated than just retrieving some time-series data out of ClickHouse, and the doc fails to make that clear.