That's exactly how I feel, except you're always running a risk. Somebody on the team might read the YAML standard and discover a bunch of cool features to use,

That's exactly how I feel, except you're always running a risk. Somebody on the team might read the YAML standard and discover a bunch of cool features to use, and next thing you know, you have a lot of lines of YAML that are a razor's edge away from an edge case, and half the people on your team don't understand why. In your config files, no less, the last place you should have to devote scarce time and technical brainpower. Any sufficiently powerful language has the same hazard. It's natural to want to know everything about the technology you use and want to use everything you know. It's how we expand our skills, and the sheer pleasure of it is why a lot of us got into programming in the first place. But not everybody considers the interests of their team and their coworkers when they choose outlets for that impulse. A single selfish person can run a C++ or Scala codebase clean off the rails. It takes strong management to make sure the team has good collective boundaries and to crack down on people who go too far. Since senior developers are now largely left to manage themselves, you're at the mercy of the savant who knows 98% of the YAML standard to understand why they're being asked to only use it 70% of it, and to pay attention to the opinions of people who know less (about YAML) than them. Or you can just use JSON or TOML.