I think we're largely on the same page vis-a-vis the performance vs. ease of mutating tests tradeoff. In my personal workflow, tests are cheap, so throwing them away doesn't really bother me. The performance hit bothers me a little, as it would potentially cause problems for some people using my A/B testing library. If your performance needs tolerate a read on every render of an A/B tested element and a write for every unique visitor seeing an A/B tested element, though, mazel tov, your way should work swimmingly.
For folks interested in weighting without the database: you can do unequal weights with the modulo method, too. Imagine if you had five choices as follows: [A, A, B, B, B]. This array can get computed once from an arbitrarily simple (or complex) representation in your program, and then cached somewhere where accessing it is very fast. (I stick it in Memcached.) Thus you get all the weights with none of the calories. You don't get trivial re-weighting, though.
The problem isn't how expensive tests are, it is that someone is waiting for the test answer. Throwing away several days of data causes them to wait longer, which makes for unhappy product managers.
For folks interested in weighting without the database: you can do unequal weights with the modulo method, too. Imagine if you had five choices as follows: [A, A, B, B, B]. This array can get computed once from an arbitrarily simple (or complex) representation in your program, and then cached somewhere where accessing it is very fast. (I stick it in Memcached.) Thus you get all the weights with none of the calories. You don't get trivial re-weighting, though.