I'm splintering the discussion going on at T=Machine (and to a lesser extent, Jeff Freeman's blog) because the discussion is already fragmenting, and I prefer typing long pieces of text in LiveJournal to comments in WordPress. Shannon has also reposted one of his responses in a previous post of mine, which also covers some of what I'm going to talk about here.
Before working on Dungeon Runners, I worked on the NCsoft billing and web tools team, and I actually did some work on the back end process for City of Heroes in-game petitions (the CoH game server would put a petition in the database, our process would poll the database and use XML-RPC to submit petitions to Right Now CRM software, which the GMs and CS people used to view petitions). I can say first-hand that at least some of the internal fields that Cryptic had to expose were invaluable, because it meant that the petition processor could provide a lot of data to Right Now beyond just the text of the petition.
On Dungeon Runners, we seem to have the same experience - some of the data are important for customer service tools, but most are not. If they're important to customer service, we try to (or plan to) expose them. We also provide a network interface and protocol documentation for requesting changes to the DB (to preserve cache consistency). That doesn't mean a mandate to expose all internal data is reasonable, but there is definitely value to exposing some of the data - and in a way that the developers writing the tools understand, which means accessible via SQL.
We're also working on providing more information for data mining and web display, but the trick here is that this data doesn't have to be perfectly up-to-date, so we can update it in the background without delaying interactions with the live game. Again, the value of this is that data miners, designers, and so on can make sense of the data without my constant involvement. We don't lose any performance by doing this work lazily and keeping it separate from the authoritative blobs, and our total dev time is reduced because we can use so much existing database infrastructure. We also win by having only one storage engine for all the data.
I touch on it above and in my other blog posts, but another advantage bears further explanation: we can easily replicate the relational data to another database that web servers talk to, and suddenly we've got a wealth of live data out on the web. Well, so far, it's not a wealth of data, but we're constantly improving it, and it's easy to improve because the steps involved are a) store the data in the database, b) write ~10 lines of PHP (mandated, sadly) to pull it out of the database, and c) drink a beer.
My feeling is this: there is enough benefit to having game data in relational format that it's worth using as a starting point. On the other hand, there are enough hurdles involved in reflecting game state in a relational database that you have to be careful. I don't fully agree with Cryptic's approach, but that's mostly because I think they go a little too far - not because I think they're going in the wrong direction.
Maybe one of these days we'll see an MMO that has a 1000-machine Oracle cluster with a 3:1 machine:DBA ratio, and they'll prove us all wrong on how to use databases in games. Until then, the debate rages ;-)
On a more serious note, what do you actually end up using the data to figure out?
Here are some examples:
There are two blogs I know of by people who are very active in this field - the aforelinked W. Can Fix That with Data, and the official Orbus Gameworks blog (where Orbus is a company whose business model is "help companies use game metrics").
The downside to game metrics is that you can generate terabytes of data in very short order, and storing that much data (much less processing it when you want to answer a question) is very serious business.
Post-hoc analysis is valuable too, but you can run a successful data-driven MMO without it, as long as adding new analysis modules is fairly easy. Realistically, designers are probably only going to care about 10 or so metrics, and it's hard enough to get the less-analytical types to care about those.
It helps, though, that we have someone on the team who can devote significant time to just poring over any data we gather (we also have infrastructure to generate regular reports when we decide we need one). But I've got another post kicking around in my head on the subject - still in the formative stages, but I've definitely got a lot to say here!
Just to throw-in my own 2 pennies: Answering your question is where the real value of game-metric expertise lies.