As for custom metrics, it's always on the producer to make sure the correct values are ingested.
We have many types of custom metrics in Dynatrace. If you mean custom metrics that are ingested via the API, this is the users responsibility.
As for custom metrics derived from other components (a.k.a. "calc" service, log,..etc. metrics), this could be done but only within a limited scope. The problem is that metrics usually have a dimensional splitting. Storing 0 instead of nothing for something that is missing would mean that one would need to infer the dimensional splitting. Problem here is that there are infinitely many splittings that do not contain data compared to a finite amount of splittings that do contain data. So that would probably boil down to manually defining for which splittings a 0 should be written. This cannot always be foreseen. Also, the processing becomes more costly because some state needs to be held. And last but not least: you will not be charged DDUs for a missing datapoint, but writing a 0 will cost as much as writing any other value.
The question is still not so much about the storage backend (Dynatrace vs. Grail), but the data producer. As for the custom metrics produced by Dynatrace itself, I believe that it is unlikely that something like this will ever be implemented, because of reasons stated above. The default()-operator provides a great workaround.
All in all, the approach that Dynatrace follows here is sensible and correct. There is a difference between having no data or data with the value of 0 (see also here: https://images.app.goo.gl/PKUHd1ZqkseNxmtW8).
