I don't think I'm missing any point, and I don't know why you think I claimed that you're "advocating using UUIDs instead of fixing the underlying security issue". I thought it was pretty clear that my statement was addressing "there's usually no reason not to do it". I don't think that's true, because like I said, obscuring the issue can make it more difficult for it to be detected.

No, I don't think you can say "a random ID like UUID is objectively better than a serial ID in nearly every regard". Firstly using random IDs like UUIDs often requires introducing libraries to generate them. Any vulnerability in those libraries can now be in your app too. Just look at the number of incidents that happened with NPM this year. You could argue that the chances of a library getting malicious code injected into it are lower than someone guessing IDs in your app to see data they shouldn't see, but which one has worse consequences?

Secondly, from a performance standpoint, UUIDs are objectively worse because they take up more space and "that's not something that should be taken for granted in a production setting".

Ultimately more code = more problems. If you have a distributed system that requires universally unique IDs, yes, UUIDs are going to be far better than some sequential sequence. On the other hand, if that's not the case, then simpler is better. A pen doesn't always replace a pencil.