You are right to use IDs , they are specifically chosen to be unique identifiers for this purpose. They can point to things that change without needing to be changed.
Web browsers use these IDs and ensure they are unique , so you get a smoke test for free. At least that is the theory, we've extended this paradigm so far beyond where it started.
For any non-trivial application you will need to stick to IDs to cope with the the rate of change and its a problem that a lot of frameworks don't see the clear value in using determinate ID's instead of ephemeral ones.
Ephemeral ID's just push the problem into somewhere else by requiring some kind of mapping layer between them and the real ones, i can guarantee someone at every org that uses these will spend an inordinate and painful amount of time navigating and debugging these abstractions. As a tester its important you can connect that time to the original decision to use the framework. If you are not careful that can end up happening on every test failure , keep tests and apps as simple possible.
There are other uses for IDs , if you want your app to be accessible to people who might not be able to see, might use different input methods or might want to use your website on unusual devices then these ID's become very important.
The worst argument for not using persistent ID's is security , you are only adding obscurity and hackers will know how to reverse your framework's obfuscation. Your backend should be secure enough that knowing these IDs will not compromise it.
Having a standard name for a thing across the whole of a project is an important ingredient for software quality , it reflects a common understanding which even if wrong is of more use than multiple competing definitions because you can fix it in a predictable amount of time.