I had exactly this discussion with our developers recently, and I do not have satisfactory solution.
First, disclosure: I avoid XPath locators like a plague. They are flaky, slow and brittle.
Adding IDs is not consequence-free: IDs have to be unique, and adding additional elements with same ID would break the old test which used it.
Name-based locators are more forgiving: if you have few elements with the same name (and you are prepared to handle the ambiguity), it is easier to recover by finding the right one from the list. IDs are often generated by widget itself, like some Angular/Material widgets, so adding a custom ID is not even an option.
Names work perfectly for things like rows, where every item in a column might have same name, and can be distinguished by some other attribute.
One solution (for lucky few) is to have a naming convention/best practices agreement with developers to add "name" attributes. If accepted, missing locator is breaking such agreement (definition of done), and is added on request.
Another solution (or for locators in pages which are not under active development, say if backfilling e2e test for existing old pages) is to have one "umbrella" bug to add locators, so developers can add them (and have a bug number to work with - in our process, even such trivial change has to have associated bug number).Such umbrella bug gives you a head start: it is already approved, scope and consequences are known. Any other bug would have to compete for resources.
OTOH you can just use CSS locators, which can use hierarchy of elements, but are more sturdy and faster than XPath. Of course some of such CSS locators would be long and complicated (worse than name-based locators), but you do not rely on co-operation (or lack of thereof) from developers, so you can advance faster, without waiting for developers and their goodwill.
This is all complicated by time pressure, and possible split between application developers and coders of automated tests. Because like automated testers, developers have their own priorities, and often making automated test coders more productive is not a metrics they care about (which relates to recent debate about different metrics while developing app and testing it).