A lot of things that we do for security or privacy are bad for performance, but I think they are still good tradeoffs.
Or worse, the right result for the wrong reason. I've actually seen a case where creating a new entity in the application populated X records in X child tables, each with a sequential ID, and as a result all of them had the same surrogate PK. They were 1:N relationships in principle, but the software wasn't feature complete yet so the actual records were all 1:1.
Years later one of those tables finally received some extra records, and it caused a really weird bug because a query had accidentally used the PK instead of the FK as a join key, but for years it had happily chugged along because the two columns were in sync.
In an environment where millions of events are processed every second, being able to uniquely identify them is a must, and temporal keys are not always an option.