Think of the alternative: - A user uses the product for one hour and they pay the same amount as they would if you use it for the entire month.
I think that's where the cap becomes important. Think of the cap as a traditional user based pricing. Now only in the case where EVERY single user ends up using it VERY actively will they ever pay that amount.
In every other case, they end up paying less, because they're only paying for the value.
So if Slack is today charging $8/user, but instead they change their model to max $8/user, but users who message lesser pay lesser than $8, then it's a fantastic decision commercially. Esp as an org scales.
I think the real issue is that, when you add a new user, you're not really sure if they're going to use the software fully, so you're hesitant adding them (think about buying a salesforce license for a solution engineer). But if someone said "hey, you don't pay the full amount, till they end up using very actively", then you're more likely to invite more people because the risk of racking up costs is lower.
So the hope is also that a pricing like this leads to more experimentation and wider adoption by a customer.
But imagine tools, where there is high aversion to adding more seats unless you're 100% sure. Like CRM & CMS systems, or like Support tools (Zendesk), or shared inbox tools (like Front) or project management tools (Asana) and so many others.