Although I now use a debugger, I can't help but feel improper for having abandoned his rule. While a debugger provides for an easier programming experience, there is something to be said for personally combing through every line of code to find a bug.
I can't relate to the argument of the teacher. To me, "understanding" a device means to be confident in what actions to the device will result in what consequences - and what internal processes are responsible for it. I'd think getting as much feedback as possible on your commands can only be helpful for that - and forbidding a debugger seems to me like artificially hiding what is "really" happening and denying feedback that would be readily available.
... But wouldn't it be even better to learn by assembling one with transparent materials and a magic device that could "pause" the whole engine at an arbitrary point in time?
While it's true that it will enable some students to simply "fiddle until it works" without understanding, I think that's a small price to pay for the benefit it brings to the genuinely-curious students.
understanding the thermodynamics of gases and mechanical properties of steel are what help you build a combustion engine. i think this is the point of the article, that stepping through code doesnt help you understand why things happen.
when you know that pressure is proportional to the temperature and the inverse of the volume, and that steel yields at 36K psi, you understand why the piston shaft keeps breaking. those transparent materials and magic devices lets you watch the engine block crack in slow motion -- do they help you learn why that happened?
Which I think is why the closest equivalent to magic see-through engines - simulations - are actually used in engine design.