The trick of it is, it's only "bad" if you care about code quality and/or maintainability, fuzzy attributes which are seldom measured or optimized for. It's the only logical conclusion to "move fast and break things."
p.s. - the good news is, most of us are working on software that doesn't really matter terribly much, so the fact that it's bad also doesn't matter very much
Unfortunately, if they don't, you only know that there exists one program which does collide with your app's mutex. Nothing more, nothing less.
> But you want to be sure that mutex is unique to your program
This one's actually impossible to test. Or to be pedantic, we know it can't be done - another app can be using your app's guid for its mutex, but in realistic cases, it's just really hard to test for. There could be even a real use case for collision - independent agents walking the process tree and relying on locks based on guids to not step on each other.
Quite a lot of people do that. It's pretty much the reputation of Stackoverflow. And of course everybody knows it's bad, but it saves time and it works and there's deadlines so they move on and ship it to production.
How to find this particular bug is not that hard, though: you're looking for a way to ensure that your program can run only once, so you use that mutex. But you want to be sure that mutex is unique to your program and not shared with others that use the same method, so you create another program that uses the same method and test if they conflict. If they do, then your mutex is not unique to your program.