But if you're using a subset of YAML, you're not using YAML. You're using a custom, specific format, that's poorly specified.
At that point, you cause all of the problems that you see with, say, INI style formats. Lots of stuff has config files in some variant to INI format, but everyone has slightly different formats and semantics. Some accept spaces in section names, some treat section names separated by . hierarchically, some allow spaces in keys without quoting, some don't, some allow keys without values, others don't, etc, etc. So you can't just take an off the shelf library and parse an INI file, all of the INI parsers have to have various knobs that can be turned and overridden to parse or write out INI files that comply with everyone's different interpretation.
As soon as you start subsetting YAML, you run into the same problem. If you use a tool that assumes one YAML feature is present when writing, but your subset doesn't accept it, then you can't use that tool to produce YAML that Cargo can read.
TOML covers many of the same use cases, but is much simpler. JSON is also simpler, but not a good format for hand-written config files. TOML seems like a decent happy medium; well specified, not too complex, reasonably familiar to those who are familiar with INI files, has a data model that maps well to the kinds of things people generally want to express and parse, doesn't have arbitrary restrictions on nesting depth like INI files have.