If you only have one OK/Accept button in your entire program, you might not need to care. However, if you have lots of them, it's probably worth a discussion about why one of them needs to change. In addition, things happen like there's a checkbox in one div and the label is in the next div and doesn't have for on it, which just kills accessibility. If you do findByLabel you ensure that can't happen. Also, on many teams the people developing the code are not the ones testing it, and they may have zero idea how the cypress IDs are used in practice--which can make it hard for them to preserve the ID on the correct element when the structure changes (if they even care, which many do not). Fun fact--I just got Cypress tests up and running that haven't been touched in over 2 years.
I can't think of any time I've had problems finding an element in the virtual dom. I have had to mock things that were missing from it, so you might have a point there. I think if you're not booting up your entire app and you're not keeping your views clean of Provider crapola, you will have to mock something no matter how you're doing component testing.
I'm not worried about RTL's versions. I started out as an Authorware developer. Then I was a Flex developer, and I did my unit tests in FlexUnit. Then I was a Flash developer and when I unit tested, it was again in FlexUnit. Then I was an AngularJs developer using Karma and Jasmine. Then I was a React developer using Jest and Enzyme, with some Selenium. I've done a bit of NextJs + Playwright. Now I use React with Jest and Cypress. I don't hold my breath that React will outlive Cypress will outlive RTL. There's seldom any logic around why the community shreds a formerly popular technology, and any one is just as likely to suffer a sudden decline in popularity as any other.
You may enjoy this video describing ways of having robust tests without adding a lot of attributes just for testing:
