People want to be able to do a single swap on Uniswap, then buy one NFT, then stake once on something else, update one ENS record, etc
Yeah, monolithic chains give you synchronous composability (that is, a call to another contract is always O(1) in time) at the expense of a very real ceiling on scalability due to the O(n) cost in verifying every tx. Even with ETH 2.0, we all recognise that cross-chain interactions is going to require some form of asynchronous composability, whether it be yanking, some rollup bridges, etc.
What’s interesting however - is that this is exactly how web 2.0 API’s work, under-the-hood. Facebook, Reddit etc. are composed of many hundreds of interacting microservices and API’s in the backend. A call to an API to post may touch a caching system (Redis), a load balancer (nginx), an API backend (Django) and a database system (Cassandra) - all asynchronously during one call. And because there is no concern about verifiable computation, all of this can happen in under a second. I think it’s entirely reasonable a decentralized system could function the same way, with comparable UX.
If you have every app on its own chain, then a user has to on/off to each application chain before each of their operations, which can potentially end up costing more than if they just did the operations on L1.
But what if this decentralized database was the backend to one single, horizontally scalable chain? e.g. all sstore and sload’s were just interfacing with this database specifically? This is entirely possible if the database can scale its capacity linearly by adding more nodes. In which case, users would only be transacting with one system. Remember - L1 is never going to handle more than 1000 tokens transacted at once, which is kinda flat in the grand scheme of things.