sidecar files = one more thing that can get misplaced, corrupted and unlinked from the original. What if you want to rename our files.. you better ensure you rename the sidecar too... extra unnecessary risk.
A Lightroom user will usually move images around and rename them inside LR, because to do so externally would invalidate the file links in LR's Catalog. However I can't think when I have last done any of that. It just doesn't arise.
When LR manages image source files in some way, any XMPs follow along automatically - Raw+JPG pairs too. I believe Bridge does the same - it's some time since I have used Bridge, though, so I may be mistaken.
Compared with an ACR user, a LR user would be less at risk of, and also more relaxed about, losing external XMP data somehow. This is all an
optional redundant copy of a
subset of the data in the LR Catalog anyway (there may be other Virtual Copy metadata sets, for example, not written to file - and perhaps the preferred version of the image is one of these anyway).
I can quite see that this issue may be more crucial for an ACR user, for whom this may be the only metadata copy in existence - and who is typically more likely to manually move items around in a file browser, because more reliant on file location and naming in order to keep track of images and image versions.
There is some practical logic to a functional separation of metadata and image data; the "changing", and the "unchanging". At the same time, I can appreciate the competing attractions of having a self-contained file.
In LR the filename and the folder location are often of little interest really, and can be set up to get created hands-free, and there is little reason for the user to fiddle about with them, or even visit them using the OS directly. Image organisation can happen largely within the system, not externally at the file system level. And the image is what you see inside the program, not what you see outside the program. That's a second safety disconnect: between "virtual" and "physical" working.
RP