I love opportunities where I can fit in an indexed view. I love to see the performance of an specific query to go sky-high.
However, before I put one in place these days I consider at least the following factors:
1- can't I improve the query code
2 - how many indexes are there in each of the tables involved
3 - how often insert, deletes and updates happen on each of the tables involved in the indexed view
4- what indexes are already there in each of the tables involved, can't they be modified so that they cater for the needs of this particular query??
5 - If the current indexes do not cater and can't be modified, would not new appropriate index(es) help the query in question
6 - after trying to modify the query, and running it a few times why not run a performance tuning advisor and see what suggestions it comes out with? you might be surprised the gains you might get by adding some multi-column statistics to your database. Use with care and have a test system for this.
7 - are you monitoring the number of deadlocks, disk reads, disk writes, which objects are causing most locking and blocking, and for how long?
8 - are you monitoring WAIT STATS?
9 - from previous experience, calculated columns and indexed views together can slow down writes, and increase the number of deadlocks to an unacceptable level
10 - basically indexed views improve reading but must be done in a way that do not hurt the writing too much.
the more you know your database and how it is used, the best decision you can make. also each of your objects in your database, the more you know how they are used, the best use you can make of filegroups, disks, indexed views, and now even new features like in memory objects.
In this situation I will probably have a parallel process to keep up the stats on separate tables, either a job(s) or triggers (after update, insert, delete) so that the data does not need too much calculation when I needed to be shown.
calculated fields might be an alternative as well.