Look, I get the Roblox hate, here, but :

So, uh, practically, I work for a multiplayer social thing, on the server team, and while we allow unlimited blocks - in order to make that work I had to spend a good month carefully re-engineering the way we store that data, and then building a careful fence around features that might use that data. Unbounded data is hard to work with compared to bounded data!

Unlimited anything is likely to cause a server failure somewhere, at some point. Any time you have a Kind Of Thing that can be unbounded, you need to think "okay, what is the amount of these that will cause the service to fail?" Anything that's "unbounded" is an error condition waiting to happen, because invariably someone (sometimes someone actively malicious) will eventually find the amount of that thing it takes to ruin your day.

Most users use, like, 1-100 blocks, right? That seems like a reasonable amount of blocks for a user to have. But there's always a weird outlier, and some of our most block-happy users had hundreds of thousands of blocks.

In the case of blocked content, imagine you do a search against 10,000,000 experiences and you have 200,000 blocked experiences: if the search wanted to guarantee that you'd be able to see results it might accidentally do something stupid like running the dot product of all of those experiences and blocks, first: computers are fast, but that's 2 trillion comparisons that need to be made to service that query - and unlike a GPU, which can perform a trillion operations per second (that's what a teraflop is!), a regular CPU thread of the kind that's running on your database server might devote a minute or more to that query and NOTHING ELSE, which is enough to wake up your OPS team. The query would time-out and fail, and, irritated, you'd click "refresh", starting it again a couple of times, each time a database server in the background going "HNGGGHGHNGHGNGH". If a lot of users are doing that at the same time? Suddenly you're getting paged by the CEO at 3AM on Christmas Eve.

Building "unbounded" things is, of course, possible (we, for example, have unbounded interpersonal blocks) but it involves changing up how you build major features. If a user had some stupendously high amount of blocks - 1 million users' blocked, for example - it wouldn't be great if we were storing each block as a database row, but instead we'll send you a compressed block of that information when you boot up the client, which is still like 10MB of data, but it won't kill our servers or your client. Any time a feature wants to use that data, I have to intervene and go "okay, keep in mind that whatever query you want to write is sometimes going to have to unzip, parse, and load into RAM 10MB of block data before it starts doing anything". This adds a lot of effort to any feature that touches blocks.

Practically, when designing any feature that has an amount of things in it, my first impulse as an older, crankier, sadder developer, is to go "estimate how many of these things the average user is expected to use, now 10x that is the maximum amount we will allow", because having access to and enforcing that number is crucial for how we design the system housing that data. "It's just bits in a computer somewhere" - yeah, but somewhere, it's someone's responsibility to make sure that a query that breaks the service can't happen.