The real question here seems more like when should you teach goto rather than if you should teach it.
The first example programs should certainly not be looking like those we wrote on the machines in WH Smith on the way home from school:
10 PRINT "HELLO WORLD!" 20 GOTO 10 A while true construct is more sensible here. However, if you introduce your students to programming by demonstrating the low-level operation of the CPU (fetch/decode/execute) then it's more likely that you'll need a force-pc (although typically it also needs to be conditional).
The assembly language constructs typically don't quite match high-level languages exactly (e.g. count down rather than up, in a loop to allow compare-and-branch-if-zero), but at some point your course will probably link high level languages to machine operations.
It should be easy to explain that modern high level languages are designed so that humans can understand the code. That is why there are usually several different ways of expressing control flow even though to a beginner they all look interchangeable. In the absence of any more specific reason, goto is likely to come at the end of your list of 'possible control flow changes' and probably needs to be introduced as an instruction which has been mostly replaced in modern programming, because other constructs are better, not simply because goto is bad.
The best reason I can think of for introducing goto is that the concept might help when it comes to explaining hardware interrupts (being the most important part of CPU architecture which isn't even mentioned in far too many courses).
