Hmm, I think there are several different reasons why the subrequest limit actually doesn't apply to your scenario.
First, Durable Objects and Workers KV requests do not count against the 50-subrequest limit. It's HTTP requests to external servers that count.
Second, with the Unbound billing model, the limit is now 1000. The old "Bundled" billing model is really intended for "configure your CDN" use cases where you're mostly just rewriting a request or response and proxying to origin. For whole applications you should use Unbound. (Note that with Durable Objects, the objects themselves always use the Unbound pricing model.)
Third, to address your specific scenario:
> If my usage pattern is e.g., sharing docs with many users, how would I let more than 50 users access a doc?
If you mean you have 50+ users connected via WebSockets and you need to send a message to each one -- these messages (on already-open WebSockets) do not count against the subrequest limit. Only starting a whole new HTTP request or new WebSocket would count.
And for "fan in", these would be incoming requests from client, but the subrequest limit applies to outgoing request. There's no limit on number of incoming requests.