Background: I'm a hiring manager for sysadmins, tech support people, and the occasional front-line manager thereof, and have worked in and interviewed for those positions most of my career, except for a brief stint driving trains -- of which the interview phase was surprisingly valuable in giving me an alternate view of how interviewing can be done.
Whilst I have restructured my company's hiring practices (for the roles I'm involved in) to include MT-inspired behavioural questions, I firmly believe that they are not enough, on their own, to be able to sufficiently determine a candidate's suitability for the role. Historically, my company's interview process was centered around a written technical quiz, and I haven't removed it from the interview process (and I have no intention of ever doing so).
The problem is that the candidate gets to pick the stories they tell, and while you can (and must!) interject to get more information about the candidate's thought processes, if I'm getting a bunch of stories about tracking down performance problems, and I need my candidate to be able to fix performance problems *and* write some scripts, I can't tell if I'm getting a certain set of stories because they're the most appropriate ones or because they're the *only* ones.
My guess as to why you perhaps don't do a big "technical" interview (where I define that as "assessing the candidate's ability to recall and apply the industry-specific body-of-knowledge", rather than firm-specific "fit", or other "soft" skills) in the legal profession is that you've got to pass an (as I understand it) strong technical assessment (a bar exam or equivalent) before you can even hope to get a job *anywhere* in the industry. As such, you can be fairly sure that any candidate who comes to you having passed the bar exam will know the basics of the law.
No such qualifying exam exists in IT, and so we've essentially got to do the equivalent of a bar exam to every candidate who comes through the door, just to make sure they've got the slightest hope of being able to do the job. (Before you ask: no, a degree is *not* sufficient -- I taught some classes at a University, I know what goes on, and there are no shortage of graduates of "reputable" CS programs who I wouldn't trust to plug in my toaster, let alone administer systems). I suspect that the lack of a baseline industry-wide certification, and a very different focus on what makes a "good" employee, pretty much explains the difference in interview structure between the two professions.
As an aside, I've actually been through (and passed) the Google interview process - in many ways, it has elements of behavioural and roleplay interviewing as part of the lengthy technical interview you go through. The pre-qualifying phone screens were in effect "tech quizzes", or "bar exams", and the in-person interviews were, for all intents and purposes, role-plays of various aspects of the day-to-day work in the job I was interviewing for. There wasn't a formal "behavioural questioning" part, and no interviews with "the hiring manager" (I think you get assigned to a team after you join the company -- in my case, the team I was interviewing for hadn't been formed yet, and they didn't have a manager at all yet), and that might be hurting them a little bit, but it's not a million miles away from the spirit of what MT recommends, in my opinion.