Here is my take on the why not JSON / why not YAML questions: https://blog.ometer.com/2015/09/07/json-like-config-a-spectr...
Short answer is "UX"
There's also a historical reason, Play Framework and Akka had both invented ad hoc formats, HOCON replaced both. The ad hoc formats added things like includes and substitutions but in regex-hack type of ways. So HOCON was cleaning those older parsers up with a single actually-documented format.
Why it's not JSON:
* includes
* substitutions
Why it's not YAML:
* less confusing syntax (e.g. `cannot do that` doesn't need quotes, but `can't do that` does)
* built-in support for overrides via env variables
Why it's not JSON or YAML:
* Built in durations! No more head scratching to figure out if 5 is seconds or milliseconds. It's just `5s`.
---
JSON is a data transfer format. YAML is a markup language (or it claims to be...).
HOCON is a composable configuration language. You always need to change, override, and deduplicate configuration in sensible way, in dev, in production, machine-by-machine.
Despite a wart or two I think HOCON takes a sensible to this ubiquitous problem.
In any case, yaml.org currently describes it as "human friendly data serialization".
I don't think YAML is a bad choice, but HOCON's explicit focus on configuration yields some nice benefits.