I would not recommend doing this.
It complicates the database with what is essentially either a cached value or a report.
A cached value can be maintained better outside of the database
A report should be done on a reporting server.
I would especially not recommend using triggers to keep the value up to date. This could really slow your db down.
Your application could use any number of different aggregates and calculations, will you be adding each as an extra column on a table?
Run the aggregate query and cache the result in the application (invalidating when required), or run a report each day and use that.
On the whole adding the extra column is a very database-centric solution. If you have an application or API layer above the database you will have multiple options available to you to avoid this problem.
For example, if I always retrieve a Track and its Tags together to populate an aggregate object, then there is no need to calculate the number of tags on the database.
If I want to show the number of Tags per day, per week etc then a single col of on the track table no longer helps me. I can query Track + today's Tags from the transaction DB and the Tag frequency over time for that Track from the reporting Cube which will be optimised for that kind of query on historical data.
Even if I want an on demand up to the second report of the most frequently Tagged tracks over all time, for which a single, updated col would be useful. I would still not add the column. Instead I would have the application raise an event when a tag was added and deal with this in a completely separate solution, possibly statsd or a reporting cube that I would write directly to.