Use case 1: cheaper internal payments. When coinpool user A pays coinpool user B, that transaction does not pay mining fees, because nothing happens on the blockchain. The two users (and, in my implementation, the server) simply update their withdrawal transactions so that, when either of them wants to withdraw later, user A can withdraw less and user B can withdraw more.
Use case 2: privacy. As mentioned above, internal coinpool payments don't show up on the blockchain, so if they are not published to the world. That is good for privacy. Moreover, when user A pays someone who is *not* in the pool, that transaction appears to come from *the whole pool* rather than from user A specifically -- which is good for privacy. However, my implementation does have a significant privacy tradeoff: the server knows everything in both cases, including who *really* sent the payment, and that is bad for user privacy.
Use case 3: cheaper LN onboarding. To onboard 10 people to lightning without a coinpool, you need to create 10 outputs on the blockchain, one for each channel. Each user has to pay the full cost of the bytes consumed on the blockchain by their output (which is typically about 40 bytes), and when fees are high, it sucks. But *with* a coinpool, only *one* output is created on the blockchain, not 10. So the cost is divided among 10 users: instead of consuming 40 bytes, each user effectively consumes 4 bytes and only had to pay the cost of doing *that.* This also means coinpools have a strange property: if 40 people join the pool, they each pay *even less* -- only 1 byte was effectively consumed by each user. If 100 people join, they each pay for consuming 0.4 bytes of blockchain space. So the more people who join the pool, the lower the cost for each new entrant. (Note that this is also a big reason why Ark is really cool, as it shares this property too; in fact, I consider Ark an example of a coinpool, though the CEOs of the two big Ark companies disagree with me on this.)
