BTW, another nice-to-have feature for this benchmark would be the ability to measure "read/select" proc performance to see what benefit I am getting for the added insert/delete overhead. A "fair test" would, in addition to inserts and deletes, run a proc with a GROUP BY query on the table when there is no view and a proc with a view query when there is one.

Since the expectation is that views gain at query time what they lose at insert/delete time, it should be possible to write another benchmark that repeatedly runs something like this benchmark with an adjustable mix of reads until it finds the tipping point -- the minimum read:write ratio that would justify having the view.