It certainly depends on if you are working with natural keys or artificial ones. Somewhere in the decades of applied relational calculus we lost sight of natural keys and what those even are. In part because they are hard and it turns out that few natural keys seem to exist "naturally" in real life because everything is mutable, everything is a ship of Theseus, names/addressses/everything changes. So we've turned to artificial keys for primary keys and out of momentum most of these artificial keys are simple auto-incrementing numbers and a dumb part of brain looks at simple auto-incrementing numbers and thinks "I understand these" and "I see the patterns in these" and runs off and starts using them everywhere for business logic and corporate procedure and potentially information disclosing URLs and so forth.

(And then simple auto-incrementing numbers turn out to be not so simple indeed the first time you need to shard or otherwise decentralize your database for whatever reason.)

I don't think there's an easy answer here. We can't return to the ideal of natural keys, because reality has shown that's a pipe-dream. We can focus on using more artificial primary keys that don't look like simple auto-incrementing numbers like GUIDs and Snowflakes and ULIDs and string slugs and more, but those aren't without overhead or tradeoffs both at the database level in the raw and in the user experience and these business processes that we don't want to use our raw database IDs but we can't just give a more natural equivalent either. ("How can I refer to Issue 6D038E7E-A0D8-45EB-AAC6-1E3FEC9DA5B8 on the phone or in a meeting?" "How can I excel spreadsheet my way through the system's data without being lost?" Etc and so forth. On the one hand it feels like a failure in the system if so many processes still need to work outside of and around the system, but on the other hand humans and businesses are social creatures and these side processes arise naturally like breathing to that combination of humans inside a business.)