I can give you an answer that runs both ways.
On the one hand, there's nothing like good assembly language skills to teach you how a computer really operates. MSIL is, to some extent, an assembly-like language. On the down side, there are very few opportunities to do this kind of development any more.
On the other hand, resorting to looking at the MSIL to fix a problem is not necessarily the most direct or educational way to understand a problem. In five years of .NET programming, I've never felt the need to go there. Only once has a co-worker (who had worked at Microsoft on compiler testing) gone there with a problem that I was trying to solve, and in the end, his answer was misleading, because the real issue was based in CLR design and constraints. Better knowledge of the CLR and C# would have led to a better understanding and a real solution.
(In case you're wondering, the problem was that I wanted to use "as" for safe casting with a generic. "as" didn't work, but "is" did. My co-worker noted that "is" and "as" use the same MSIL. The real problem is that "as" only works for casting classes, and without the proper constraint on the generic declaration, C# doesn't know whether your generic type will be a class. In fact, the types I was using with generics were value types; "as" couldn't work for those at all.)
Rather than going for MSIL skills, I highly recommend Jeffrey Richter's book CLR via C#. Even after years of digging hard at into C#, this book is still full of revelations - I learn something from every page.