Required encryption with MSRPC-based services

I've been studying some of the core services that show up in Windows
Server environments and have noticed a trend that I'd like to better
understand. I imagine the answer may lie deep within some
architectural team at Microsoft, so this seems as good a place as any
to start my inquiry.

Not surprisingly, many of the core Windows services make use of MSRPC.
Based on my reading about MSRPC, one of its desirable features is that
it makes it easier to write server-to-server systems without
reinventing the wheel in terms of protocols, and in doing so makes it
easy to do things like encrypt traffic. Indeed, many of the core
services I've studied most closely (File Replication Services, AD
Replicaiton, Exchange Mailbox Moves, and most recently, Exchange 2007
server-to-server traffic) utilize the option to encrypt MSRPC traffic.

What's curious (and frankly, kind of annoying) is that in all cases
there is apparently no way to turn the encryption off. On multiple
occasions I've had this verified by Microsoft Tech Support folks, but
nobody has been able to give me a good reason "why". Most would agree
that more security is a good thing, so the fact that they encrypt is
certainly a positive sign. But the fact that there's no option to
disable it seems to go against a fairly basic software engineering
principle, and, indeed, runs counter to most other Microsoft systems,
which for the most part are highly configurable, if not through
pleasant end user GUIs, through the registry.

I'm curious if anyone has insight into why Microsoft has chosen to
"hard wire" so many services in this way. Customers often have
motivations to see traffic "in the clear", whether it be for
debugging, auditing, or if they have a hardware-assisted network
encryption device to which they'd rather offload the task as opposed
to expensive server hardware.

Anyone know?

--
Phil