Junior programmers aren't aware that reading code is hard, since they've never really been forced to read much code (AFAIK there's no point in a CS course where "scour this 500KLOC non-didactic codebase for the cause of this bug and fix it" is assigned.) Because they aren't aware that reading code is hard, they think that code that's hard to read is a code smell, whether the complexity comes from obfuscation, or just the inherent complexity of the problem domain.
They also don't know that they don't know this, because they've seen code that's comparatively easy to read -- why, they've written it themselves! Their implementation of only the minimal requirements of the domain is much clearer than someone else's complete solution with all its required business-warts. As such, obviously, throwing out the previous complete solution, and filling in the gap with their own minimal reimplementation, is an improvement. (They don't notice that after fixing the ensuing regression bugs, their version now bears a much stronger resemblance to the previous one....)
Eventually, you read enough code that you get used to that particular "smell," and you realize that it's not really pungent in the way the other smells are. The "complex problem-domain, completely expressed" smell becomes the grease on the equipment[1] -- the sign of a well-patched and long-running system.
---
[1] http://www.joelonsoftware.com/articles/Wrong.html