Roy ... thanks for the response. I really mean this because I haven't received one previously on this subject.
You're right -- T-log sequential writes can really suck. Probably the best thing you can do is avoid parity-based RAID. I am unfamiliar with the improvement in logging and locking with In-memory tables. But a question I would have on this is why can't the same logging improvements be made to disk-based tables? And is there a problem if you reverted back to a disk-based table without a full backup? I suppose that like anything new, it is wise to run some rigorous tests to make sure it is right for your particular shop.
Also to that point, in a perfect world I would put everything in memory, or at least on SSD. But the realities of life are that IT has historically been viewed by top management as overly expensive. Mind you, I don't agree with those twits. Nevertheless, IT is constantly defending and justifying costs with every new silver bullet that comes along. It might be open source (or open chaos as I like to refer to it), appliance databases, outsourcing, etc. Maybe in time this will work, but my experience is that "sexy" approaches like SSD have to be a solution to an existing performance problem, not a proactive, anticipatory solution. I could only wish that we all could work in companies where top management would view IT as a competitive advantage, rather than a necessary evil.
Thanks again for the discussion.