Leaking users private pictures / documents / whatever, will also kill a company.
I guess one could maybe circumvent this, by using a hash of the ID, but then you have to store that somewhere too, and you're back to square one.
Nevertheless, I like that you fixed the main flaw with ULID. Also you provide way better insight into the tradeoffs, so kudos!
Hashing the IDs won't solve their lack of entropy. Crude example: If you hash your pincode I still have only 10^4 values to try.
The easiest way to fix this is to add an access token column that is cryptographically random and use both the ID and the token in the URL.
If you trust the 80 bits already in the ID the token only needs to be 80 bits for a total of 160 bits of entropy. But if you do that you have to make sure that a missing ID and invalid token are handled identically from the attackers perspective (same reply, same timing).
Yes and no. It would still significantly largen the search space, as an attacker wouldn't get a point of reference to latch on to.