this is a good skill to have. however, there are a lot of problems / domains where reading the source isn't enough. debug the operation of compiler logic, for example. what's really important is to know how the algorithm has been implemented and how the algorithm, as implemented, is interacting with your current problem / use case.
if understanding the algorithm involves boning up on two semesters of type theory or graduate-level courses in algorithms, number theory and abstract algebra, as debugging problems in modern databases, compilers and high-performance integer libraries would, then having the source code is probably not going to help you as much as you think it would...
Long term, I think having a solid grounding in (to continue your example) real world compiler infrastructure and the ability to fix bugs in your tool chain is going to "help" you an awful lot more than getting whatever instantaneous problem you have fixed.
I mean, sure: for everyone there are some problems that are so obscure as to be near-impossible. But if you go through life always deferring those solutions (by calling tech support, or giving up, or playing voodoo games until the problem goes away), that set of problems will never shrink. You'll end your career, broadly, just as incompetently as you started it.
If, on the other hand, you make a practice of always digging for bugs, even across library boundaries into "other people's" code, you'll find over time that things like compiler bugs stop looking so scary.
if understanding the algorithm involves boning up on two semesters of type theory or graduate-level courses in algorithms, number theory and abstract algebra, as debugging problems in modern databases, compilers and high-performance integer libraries would, then having the source code is probably not going to help you as much as you think it would...