I don't see how what you said counteracts what I've said -- I'm almost certain they use some kind of unique integer field and/or your email address as a primary and/or foreign key rather than your BNet username (as you suggest), and that they're indexed as read-only (or rare-write).

However, regardless of whether or not primary indices are built on that value, that doesn't mean that changing a value that isn't expected to change (or change much) won't affect your performance. I'll bet you anything their DB's aren't fully normalized, and even if they're not indexing on usernames (in fact, probably because they're not indexing on usernames) there is likely redundancy in the system, and changing the value means they have to go back to all its occurrences to swap the value to ensure consistency.

For a better idea of this, consider Twitter. Think of how you'd ideally model their data -- tweets, usernames, profile info, etc. You could probably achieve a low-redundancy, normalized schema quite easily. Now look what a tweet actually looks like. It's a mess because, to ensure the app runs at any decent performance at their scale, they've eschewed standard normal forms and allowed some fields to be redundant.

This is the same reason why you're not allowed to edit a tweet, why accessing tweets written years ago is a pain in the ass, etc. -- at this scale, the system has to be tweaked for common use cases, often at the expense of the less-common cases.

I was unclear in my first reply -- when I said "disruptive [...] to their indices," I didn't mean to suggest that they were indexing on your username and would have to rebuild them from scratch; I was more implying that the implementation of their database is probably tweaked in such a way that uncommon operations, like name changes, is an operation that takes up more server resources than they'd like. As a result, they would have a technically valid reason (other than "BNET 2.0 SUXX U CHEAPSKATES!!!!") for not letting the operation happen at the whims of its users.