I personally find YAML more readable than XML, and seeing as beyond the initial creation (in ROS 1), package.xml is maintained by hand, I find it weird that ROS 2 with a new custom build system (ament) decided to go with package.xml instead of package.yaml (or support for both like Log4j 2 but supporting 2 formats is hard).
I’m pretty sure I’m missing on something here beyond just compatibility with ROS 1. I know its a small (non-)issue, but I found that only ROS configuration and Dockerfile are not in YAML (personal anecdote, YMMV). Rest of all configurations (including parameters for nodes, CI pipeline) are in YAML. Even command line tools like rostopic and rosservice have their inputs and outputs in YAML format. What’s the reason for this discrepancy?
See the rationale section in REP-0127. The gist is that package.xml gets parsed rather often and Python XML parsing was found to be an order of magnitude faster than YAML.
Another benefit of XML over YAML is the ability to define a schema to check the format of the input structure before parsing, thus avoiding the need to monkey patch the interpreter for every corner case or ill formatted files by the users. The user can also get constructive feedback from the schema validator as to exactly what they did wrong, and how to comply. Additionally if you make an interpreter in a different implementation or programming language, everyone has common definition of the format structure that is perhaps more rigorous then written paragraph docs or less ambiguous than just several stock examples.
I don’t think catkin or ament are using schema vacation presently, but the community has defined a XSD to express the package schema.
I personally prefer/enjoy using yaml for lightweight and informal configuration formats, but have found defaulting back to XML for anything more extensive or formal as beneficial in clarity and maintainability. Plus if you have a reasonable text editor with syntax highlighting and auto complete, the extra markup just kind of fades into the background.