Revealing your database ids by itself does not make your site insecure. And hiding them does not automatically make it secure.
But there are people and companies that decouple database ids from public identifiers as part of defence in depth.
It'll be a little harder for an attacker to get to related entities. E.g. in a list selection, you might communicate the index of the option chosen, instead of the identifier, so that it's not even possible to submit an option that wasn't in the list (the alternative is to let them be submitted but invalidate them on the server, which is also safe).
Aside from security, it is good encapsulation. Database ids should probably be considered an implementation detail that shouldn't be exposed to users. You may want to change them when moving database server or something. Or you may not want to show how many orders you've had, if order numbers auto-increment.
Considering user experience (and maybe SEO), a meaningful slug will be better than an arbitrary number. But you could do both to combine ease and UX.
That said, it causes extra work and perhaps extra queries, and might encourage bad practices like leaving search results in memory between requests. If you do proper input validation and keep yours ids stable (even when moving database), you can have a functional and secure site while exposing ids.
What I personally tend to do, based on my opinion and not on any kind of research, is to do a simple bijective encoding of ids. This:
Note that this addresses the user experience and ease, but doesn't help security, and I still have to keep my database ids stable.