I guess I was really just trying to challenge the inherent "high means all is well, low means trouble" assumption that accompanies the BCHR.

As Elisabeth points out, a high BCHR can hide some very inefficient queries – which is the overriding problem with these sorts of averaged values. Also, a drop (or rise) in BCHR could mean anything…so you'd need to look at other data, such as query response times, queries doing excessive physical or logical reads, queries causing blocking etc, to work out what was going on.

So why not forget the BCHR and, as GSquared says, just track the stuff that actually means something?

If you have performance issues you'll spot them in specific query response times long before you'll spot them in the value of the BCHR.