Excellente question !
TL;DR: dans ce cas : non.
Avant tout, il faut bien comprendre la raison pour laquelle je donne ce conseil (je ne dis pas ça pour vous particulièrement, mais pour remettre le contexte à tout le monde) : break; (et continue;) risquent de poser problème lors de l'évolution du code (p.ex. si votre boucle while est comprise dans une autre boucle plus large et que votre boucle while est finalement changée en un if ; ou, autre exemple, si on ajoute une boucle supplémentaire autours du if qui break; etc. etc.)
Évidemment, cela suppose que « l'on ne voit pas », lors de la modification, que l'on est en train de casser quelque chose et donc, souvent, les causes sont multiples : le break en question n'étant qu'une partie du problème, l'autre étant que le code en question est trop gros, mal écrit, etc. pour que l'on voit clairement sur quoi porte le break;
Tout ça pour dire que la règle « jamais de break; » (comme toute règle) a ses exceptions. Mais je préfère EN PREMIER me focaliser sur la règle, plutôt que sur les execptions ; d'autant plus que pour break et continue c'est trop souvent la paresse qui conduit à leur utilisation, plutôt que d'avoir bien réfléchi au problème.
Pour vous répondre maintenant :
dans le cas précis que vous citez, et en ajoutant d'autres hypothèses importantes (genre : pas de lien logique (implication) entre condition1 et condition2 ; les instruction2 peuvent modifier la condition 1, etc. etc.) alors, non, dans le cas général, il n'y a pas mieux.
Mais dans ce cas, il faudrait simplifier au maximum (comme vous l'avez fait) l'écriture de la partie concernée, potentiellement problématique : en l’occurrence : faire que Instruction 1 et Instruction 2 soient le plus simples possibles, genre un seul appel de fonction (souvent les fonctions sont justement l'autre moyen de résoudre le problème potentiel).
Par ailleurs plein de sous-cas spécifiques de votre exemple pourraient par contre être simplifiés (genre : SI C'EST POSSIBLE : mettre Instructions2 sous le if (+ négation de la condition 2) [ je sais bien que ce n'est pas possible dans le cas général !!]). Et dans de tels cas, il faudrait bien sûr écrire sans le break;
Pour conclure : le mieux est toujours d'écrire directement et totalement (et clairement) la logique du problème ; faire cet effort conduit souvent à des solutions qui n'ont pas besoin du break;
Si ce n'est pas le cas : la boucle (cassée par le break) ET SON CONTEXTE D'UTILISATION (e.g. est-elle elle même dans une autre boucle) doivent absolument être le plus court possible... ...en modularisant au moyen de fonctions.