In General: Learn from the Contrast
I think it's important to both read good and bad code.
If you read ONLY crap code, you probably won't learn much from it. If you read a mixture of good and bad code, you'll probably learn more from it. The good code is supposed to teach you new things, the bad code to show you the general mindset of the average programmer and the pitfalls to avoid, and to make you realize how much effort can be saved with good code.
The contrast is very important in helping.
Similarly, for a different domain, Stephen King says in his memoirs on writing that recommends to read bad novels. You can't appreciate the good ones if you don't read bad ones, and there's a whole breadth and range of ways to approach writing. You might be surprised by what you find in the bad ones.
That being said, don't spend your life reading code that looks like it's been written by a herd of monkeys or bored students with no interest in learning programming and who just an one CS elective (except if that's your job, then it's helpful to learn their common errors and to understand why they occur frequently).
It's very important to compare and contrast. For instance, take the source code for the 3 major BSD systems: NetBSD, OpenBSD and FreeBSD. They are very similar, yet their implementations of even the simplest tools differ (
cat, etc...). And surely there's one you'll prefer over the other (haven't checked for about 8 years, and not wanting to be judgmental here, I just want to give a personal experience, but at the time the OpenBSD code struck me as largely more elegant than the others, and the NetBSD code to be quite instructive to learn about using macros and pre-proc guards).
For In-House Code: Learn from the Context
You mention that it's about reading code written within your company as well. In this case, I'd say it's even more important to read some of it. It's very interesting for you to get an understanding of the team's mindset by looking at the code, but it will also give you a deeper understanding of how your programs work.
Finally, there's a very historical component to it. Don't just read the current codebase. Give your favorite SCM client at hand and lurk through the timeline of the codebase. It's sometimes very interesting to see why a code became to be what it is now. It can have gone through the hands of a dozen different programmers of different age, or you can even see that a single programmer might have matured over time. It also teaches you about certain "oddities" and mean sneaky bugs they might have encountered and why they chose an approach over another, even if seemingly less elegant.
It gives you context.