Die Frage ist nicht ob goto oder nicht, sondern die Denkweise die bei einem Assemblerprogrammierer im Sinne von Nassi-Shneidermann nicht strukturiert ist.
Empfehlung: Formuliere dein Problem zunächst als NS-Diagramm (nicht Flußdiagramm) dann kannst du es anschliessend sowohl in ASM als auch in C codieren.
In ASM macht man das dann nicht immer so wie in C, weil man z. Bsp. irgendwo hinspringen kann wo es ein gemeinsames Ende gibt während man in C dieses
Ende als Funktion ausgegliedert mehrfach aufrufen müsste. Als ASM Programmierer leuchtet einem dieser scheinbar unnötige Aufwand nicht gerade ein, aber
wenn man genau guckt, optimiert ein guter C-Compiler das letztendlich auch wieder weg und macht bedingte Sprünge draus. Wenn der Optimierer was taugt,
so öhnlich (oder unübersichtlicher und schneller) wie man das selbst auch gemacht hätte. Manche Optimierer ersetzen sogar einen RETURN durch JUMP was
man als ASM Programmierer wegen der Übersichtlichkeit nicht unbedingt gemacht hätte.

Bei SPS Anweisungslisten (wurde früher bei Siemns S5 wie Assembler von diskrekt aufgebauten Prozessoren direkt ausgefürt) gibt es übrigens zahlreiche bedingt ausgeführte Befehle.
Im uC Assembler ist bedingte Ausführung meist nur für Sprünge bekannt, Siemens S5 machte das aber für Bitbefehle wie etwa Bit-setzen oder Bit-rücksetzen. Diese werden nur dann ausgeführt, wenn ein Flag
des Vorgängerbefehls dies erlaubt. Im uC Assmbler würde man da einen bedingten Sprung machen, der mit einer Sprungmarke hinter den Bitbefehl springt. Eben nur weil es keinen bedingt ausführbaren Bitbefehl gibt. Goto ist also keineswegs eine Frage des schlechten Stils sondern einfach nur der Denkweise. C-Neulinge können sich auch mal Anschauen, was der Compiler bei Break Anweisungen (=goto) macht. Das ist schließlich ein Befehl welcher sogar als "struktruiert" anerkannt ist.