I'd never use hashids/sqids for anything secure. It's reversible by design.
However, it is fit for purpose if your purpose is showing user-facing ids that can't be trivially incremented. For example, in a url, or in an api response. It does, in fact, "protect" against the "attack" of "Oh, I see in the url that my id is 19563, I wonder what I get if I change it to 19564.”
Now, the system should absolutely have authorization boundaries around data, but that doesn't mean there's no value in avoiding putting an "attractive nuisance" in front of users.
> "protect" against the "attack"
If it's not a real attack, it's not worth protecting against even in the slightest. If it's a real attack, it doesn't matter if it's trivial or not, does it?
It very much can be worth protecting so that your users don't become dependent on thinking that increment IDs is a feature. It's not a security concern in that context, but it is a future maintainability concern where you don't intend to provide that as a feature in environments where you don't have a tight leash on how users are using your APIs.