I don't think so. There's a difference between a skilled software developer making tradeoffs under time pressure, and someone who doesn't know what good code even looks like.
If you aren't capable of writing good code, you aren't qualified to make the right tradeoff.
So you should probably limit the amount of "good code" you read when you're learning something right?
Or else (as you say) you won't be able to understand why it's good and what trade-off's it will cause...
I guess my main point is, don't dive into the linux kernel if you're learning C, as you'll learn optimisation strategies that probably aren't useful in your context and will only slow you down...
Why? If you're learning a dance, you try to copy the teacher, not other students. You don't need to study the mistakes of others, you are sure to make plenty of your own.
> don't dive into the linux kernel if you're learning C, as you'll learn optimisation strategies that probably aren't useful in your context
Unless you're learning C for the purpose of kernel programming, sure. That's not really the same question.
Well, do this in moderation, as reading "high quality code" can lead to a premature focus on code-quality.
Most "high quality code" is the result of many iterations of ideas and use-cases. And trying to emulate that style can be counter-productive in many cases.
I find going back in the history of the code-base helps you see how simple the project used to be, which is helpful when learning to code.