While the system is definitely a better solution, you also have to look at it from a database performance level. I would prefer the above, and to be honest my knowledge of databases is not strong enough to say that the below makes it impossible or difficult to implement but something that needs to be taken into account.

Spotify currently has a database that tracks the number 'Plays' each artist gets. They then roll that up into a combined number that gives them their royalty payout for the year. Have lets say 100,000 artists, that is 100,000 records accessed when they run their end of year report. On the user level (lets say you have a million users) you now need to keep track of the number of clicks per artist per user. Most likely through having each user have its own click counter table that has a record for each artist they listened to (probably through a foreign key) and then the number of clicks for that artist. When the end of the year report rolls around instead of simply looking at 100,000 records. You are now accessing 1 million records times the average number of artists a user listens too and then running calculations to figure out how much each artist gets by the user. I'm sure there is better database design then the above mentioned but you still run into a more power intensive process to calculate it.

Not something I think will completely stop companies like spotify from switching to this model but something worth considering...