My take on this is that there is not obvious reason not to, but it just so happens that typed configuration languages are not rich enough and not integrated enough to be that useful.
Those languages that arrived with the JSON hype train like yaml or toml might be great for dynamic languages, where you can load them to some native object. But in statically typed languages you are gonna declare your types, in code, anyway. So configuration providing types doesn't really do much.
Ah! Well this is the hole that Pkl does a very good job of filling!
Being able to use Pkl code-gen to create language bindings means you can take any arbitrary Pkl schema and turn it into native structures in your language, typed based on the Pkl schema. Then you can let Pkl do all the heavy lifting of parsing and validating a specific config, and turning it into native objects in your language.
So no need for double declaring types. Declare them once in Pkl, generate the equivalent types in your language, then just start using those types like any other primitive. The Pkl bindings will handle the loading glue for you.
If you replace "Pkl" with "XML", this is all exactly true for XML. Ten years ago we were generating C# classes, typed validators, and automatic parsers from XSD schemas, with automatic IDE integration and IntelliSense completions when editing the XML documents--is this just XSD for the younger JSON generation? I shipped multiple megabytes of complex manually-written XML configuration this way and it was delightful. We never would have pulled it off without XSD.
What you're expressing here is that many of the ideas from that period of xml-centricity were quite good and useful!
But xml itself was not a good language for this, because its legibility is terrible. It's just not a good format for human reading and editing. (But it also isn't a great format for machine interaction either...)
So yeah, I see it as a good thing that this seems to be able to do all that useful stuff you were doing with xml and xsd a decade (and more) ago. But it's (IMO) a much nicer way to do it.
To be fair if your config is just a structure with strings then you declare your types only once, too. Minus the codegen, but also minus the editor integration.
I'm not hating on Pkl here, we deserve better in this space, so I'm happy with more developments.
Those languages that arrived with the JSON hype train like yaml or toml might be great for dynamic languages, where you can load them to some native object. But in statically typed languages you are gonna declare your types, in code, anyway. So configuration providing types doesn't really do much.