Let's wait on the discussion on the issue to know what should actually be deprecated. This PR deprecates a lot more than what was mentioned in the issue it fixes.

I am not really sure we need to go thus far. At least for the Validator component I can tell that there has been nearly zero maintenance work during the last years for the XmlFileLoader while deprecating it would mean that bundles/applications using it would have to make the switch (I have no idea how widespread that's used though).

Let's split Validator and Serializer in a separate PR?

At least for the Validator component I can tell that there has been nearly zero maintenance work during the last years for the XmlFileLoader while deprecating it would mean that bundles/applications using it would have to make the switch (I have no idea how widespread that's used though).

Sylius uses XML files for its validator config, as one visible OSS example.

I'm with @xabbuh on this one. I understand that we don't want to require ext-dom anymore and that's great. But if someone likes using XML config files, why shouldn't we allow it optionally if the maintenance overhead is barely measurable?

Validator and Serializer have been split out, so this PR is now only about routing and DI. From them, deprecating makes sense to me: maintenance is still difficult because of XSD, but the most important is the overhead on the doc and for bundles. When there was no PHP format, XML was OK. But now that we have it, there's no point for writing XML for that anymore.

( Serializer and Validator can be removed from this PR.)

I have a hard time following this initiative to be honest. Given the impact on the ecosystem can be quite significant, I think it's a good idea to make a clear high level plan grounded by clear issues with the current system.

#60200 has a very clear problem statement: maintaining the FrameworkBundle's XSD file has proofed to be a burden, often forgotten when adding new config options.

I very much agree with @stof's comment that this is different for maintaining bundle configuration than maintaining XML loaders for routing, validation, serializer, etc. These formats have proofed to be quite static over the time, requiring less changes to their XSD files and thus less burden from this problem.
I fail to see why we split out serializer and validation from this PR, but keep routing and service definitions in. That seems highly inconsistent to me and makes it pretty unpredictable for users to know where XML can be used, and where it can't.

Further on in the discussion, other problems have been mentioned like XML being a documentation burden and XML special treatment like fixXmlConfig() is a burden. Do we have validation of these problem statements, are they indeed causing unreasonable busy work for maintainers/documentors to outweigh the deprecation impact for the ecosystem?
Note that fixXmlConfig(), despite its name, is also used by the other loaders (allowing you to type role: ROLE_ADMIN instead of roles: [ROLE_ADMIN] in Yaml for instance). I believe the new PHP object format even requires it. This partially invalidates that problem statement's relevance (it's also not deprecated in this PR, so irrelevant in the discussion altogether).

Last but not least, the alternatives are quite the moving target at the moment. Work on the JSON schema for Yaml has been stalled for some time (#59620). And the PHP config objects might be replaced with array shapes (#58771) some time in the future. I'm not sure it's great to force the ecosystem (mostly talking about the open source bundles and projects like drupal and sulu) to such new and moving formats, instead of relying on the very mature and stable XML format.
This is apart from all these alternatives relying on auto generating code in the project. Despite the formats being very cool, this has proofed to be a problem point in many occasions (it's hard to discover and many users try to find the classes in vendor/, static analysis tool can't find the code in var/, it requires booting up the Symfony kernel to generate them, etc.).

All in all, I think the timing is a bit off and we must first guarantee the new formats are stable and remove some of the troublesome points before deprecating older formats.