I use a term for that style, which is "driving seat" programming.
The analogy is that you have to be at the screen and keyboard constantly for the computer to make any progress, like being in the driving seat of a car.
It's actually not uncommon amongst casual programmers. They approach computers - not unreasonably - as machines that assist them to do tasks they'd otherwise have to do by hand.
So the idea that they remain in the driving seat is not disturbing to them. If you were walking and now you're driving, you've not lost, you've won. If you're using a calculator instead of working out on paper, you've won.
What professional programmers understand is that computers are not there merely to assist us with our own tasks, but assist others with theirs, and ideally to operate as autonomously as possible from human attention.
Our work is to configure a business in such a way that computers operate with maximum autonomy in performing necessary tasks, and that inputs of human labour into those tasks are minimised and made as straightforward as possible.
Where labour is still required (whether our own or anyone's), a remaining goal is to release that labour as much as possible from rigid schedules of attendance or need for immediate reaction to the condition of the computer, both so that labour (including our own) is available to be deployed elsewhere on useful terms, and so that the computer moves along reliably enough to make its use worthwhile.
It's much more difficult to program for other people, or for autonomous operation, than for yourself as an operator.
I'd guess that it's still useful for people to be able to program for their own use - just as not every student of English needs to aspire to be a novelist, and even the most rudimentary skills are better than illiteracy. So I don't think it would pay to set the standard too high.
If you wanted to have a discussion with your students, you'd be making the point that professional programming is about designing programs which require interaction as minimally and infrequently as possible.
Minimally, in that work for the operator should be reduced to as few steps as possible, and each step should be triggered by the least effort possible.
Infrequently, in that engagement or availability to engage is required as rarely and on as least strict schedule as possible.
Students should also be capable of conceiving and considering contingencies and variable circumstances before they arise in practice - including breakdowns, or the need to intervene and control - and apply the same analysis so that effort always remains as minimal and infrequent as possible.
The complexities of this analysis are what make it a difficult job in practice, that few people seem able to cope with effectively.
