I guess I'm not saying that there aren't conceivable situations where you'd need an ID - it's just that they're typically small issues that are easily worked around. A duplicated "for" attribute problem is going to come up when you have two forms on a page and both of them use labels in this way and use conflicting IDs. There's a potential collision, but it's relatively easy to foresee and prevent, I've never seen it come up in practice and the worst outcome when it goes wrong would be something like the user's input focus going somewhere unexpected if they click a label instead of a control.

W.r.t. CSS name clashes, yeah they can come up especially in the contexts of independently developed React components. But in my experience over-encapsulation comes up far more often in the same context. I'm almost never in a situation where I want to slot a component in as-is. Instead, I want some find grained control over its styling or behavior, and if that's hidden behind an encapsulation barrier, that makes re-use even harder.

I do think the React component paradigm has some issues, but IMO they're the same sort of issues that come up in a lot of OO designs where abstraction and encapsulation happen in the wrong places. I still feel like Web Components solves some re-use problems I rarely if ever see in practice while doubling down on ones that I do.