It's easy to blame incompetence, but startups are startups and many things are hacked together in a hurry when you're growing fast.
https://www.spinellis.gr/blog/20090805/
I believe they also for a long time had a public API^.. and I'm pretty sure they soft-delete posts (bonus that they could revive the tweet down the track if it was a 'mistake'). I don't think the Twitter team are amateurs though.
Having monotonically increasing IDs for non-distributed systems removes the possibility of duplicate IDs. In distributed systems ID conflicts are unavoidable, and you might have less conflicts if you generate random IDs, as well as it becomes difficult for an attacker to guess IDs.
^ likely it would have been rate-limited, which isn't a problem if you've got a large pool of users you can authenticate with
In parler's case, having monotonically increasing ID typed as signed 32-bit integer _guaranteed_ duplicate IDs once they reached 2.1 billion unique items. This is well-known failure mode, and yet it took them by surprise.
1) It invites resource enumeration attack
https://www.cequence.ai/use-cases/enumeration-attacks/
https://owasp.org/www-community/attacks/Forced_browsing
2) they ran out of ints. Stop me if you think you've heard this one before
I think its more boring than that. Their platform was built by amateurs who didn't know what they were doing. Things like soft-deleting posts and auto-incrementing post IDs. This is why it was so easily crawled in a day before the shutdown.
https://arstechnica.com/information-technology/2021/01/parle...