- Knowing sequential IDs leaks the rate of creation and amount of said entity which can translate in number of customers or rate of sales.

This implies the existence of an endpoint that returns a list of items, which could by itself be used to determine customers or rate of sales. This also means you have a broken security model that leaks a list of customers or list of sales, that you should probably not have access to begin with.

- Knowing timed IDs leaks activity patterns. This gets worse as you cross reference data.

Again if you can list items freely you can do this anyway, capture what exists now and do diffs to determine update times and creation times.

With sequential Ids you use one of two sequences,

- table-global sequence :: Which leaks activity signals to all users that can create and see new Ids. This is the naive sequence you get when creating an incremental Id in a table.

- user-local sequence :: How many invoices a single user has, which is safe if kept within the reach of a single user. The sequence though, is slower and more awkward to generate.

Say you have a store that allows a user to check out just their own invoices.

- store.com/profile/invoices/{sequence_id}/

This does not imply that using a random id will return you back the data from another user, so it isn't necessarily as unsafe as you guessed. You'll probably get a 404 that does not even acknowledges the existence of said Id (but may be suspect to timing attacks to guess if it exists).

---

With timed Ids you do need a data leak out of bubble of a single user. Database design should always try to guard against that anyway. That's why we salt our passwords and store only their digest (right?).