Why do so many tools have JSON config files?

This is not reintroducing anything; the BMP type is already there, although its meaning is expanded (the existing BMP type is effectively a constrained subtype of UTF-16). Although most applications probably will not use UTF-16, it might sometimes be useful in some applications where it is more useful to store UTF-16 instead of converting to/from UTF-8.

> relative OIDs already exist

Yes, although I have given a standardized name and semantics to something that is allegedly already a common use (and is one that I often use in my own projects), which the official specification from ITU admits. It uses the existing OID and relative OID types (and the same type numbers as them), and is like a CHOICE between them (implementations may treat it as such).

> BCD strings are just constrained PrintableStrings

The abstract meaning matches that of constrained Visible (not Printable) strings, but the encoding is more compact.

> UTF-8 won for all of the string types

Although it is common (and some other formats don't support other string types), I disagree, and I think that one character set cannot be useful for all purposes, and furthermore that Unicode is not that good and has many problems.

> Reference sounds like an EXTERNAL, OOB sounds like an ANY DEFINED BY

I don't think so. It seem like different to me.

With JSON, I can format the string as I feel makes sense for that specific data structure, while YAML forces me to into specific indentation patterns, and it still causes me to question every time whether the dashes in arrays should be indented or not. And since people frequently template YAML, the strict indentation has caused a bunch of issues for no good reason, including production outages (sure, shouldn't happen with good practices, but there are so many places without good practices!).

Because JSON syntax generally has only one way to represent each data type and almost every data type uses explicit start and end signifiers (except floats and bools, both of which are short and clearly stand out), it's easy to know what the context of every character is both while reading linearly, and when jumping to specific points. Meanwhile YAML has multiple ways to express almost anything, and frequently the only way to tell the current context is to read ahead before jumping back. This is especially terrible for strings due to optional delineation, because almost every bare text could be a keyword (as demonstrated by the Norway problem).

I know this is not most people's experience, but that's because readability is subjective.

    SERVER=(DESCRIPTION (ADDRESS=(PROTOCOL=TCP)(HOST=MyHost)(PORT=MyPort))(CONNECT_DATA=(SERVICE_NAME=MyOracleSID)));uid=myUsername;pwd=myPassword;