рілі?

вибачте це дуже смішно тоді. Історія складається так:
- юзаєм goto
- то надто важко розуміти
- введемо більш поверхневі конструкції,
  які будуть юзати goto під капотом, але про це вже ніхто знати не буде
- a goto заборонимо

ІМНО проблема сішних вказівників у тому, що операції *a та &a  префіксні, тоді як споріднені з ними операції доступу до елементів (a[n], a.fld, a->fld) — постфіксні, що відкриває можливість легко щось наплутати. Сюди ж — оголошення типів, де ці префікси-постфікси групуються між собою не менш неінтуїтивно. Чи рятує ситуацію посилання замість вказівника? Не бачу, які принципові зміни це з собою несе.

Якби у взяття об'єкта за вказівником був постфіксний синонім... Технічно, він є — можна робити a[0] замість *a, оголошувати вказівники як безрозмірні масиви. Але таке постфіксне вирівнювання не є загальноприйнятим.

Це правдиво лише частково, те, як реалізують посилання компілятори не є останньою інстанцією. Так більшість з них (принаймні найвідоміші), реалізовують посилання через константні вказівники, але це не означає, що це синтаксичний цукор саме для С++, як мови.
Посилання також мають свою семантику:
1. Посилання завжди створює псевдонім чинного об’єкта, на відміну від вказівника, який може мати значення nullptr;
2. Посилання не можна встановити повторно, воно завжди вказує на той самий об’єкт протягом усього свого життя;
3. Посилання може продовжити термін життя об’єкта;
Таким чином, на мовному рівні посилання є власною сутністю. Решта – деталі реалізації.

Власне, ще раз, внутрішньо посилання може бути реалізовано як вказівник, але стандарт ніколи цього не гарантує.

Ну і що тут дивного, в цих концепціях чи в такому розвитку?, як ще виконати елементарні засоби контролю потоку виконання програми окрім як експлуатувати ці спеціальні (для того й вигадані) інструкції і створювати надбудови на них, - умовні переходи(if\else) й цикли(for\while, що згадано вище) теж надбудови/конструкції на jmp-ерах (je, jg, jl і т.п.)
    І ніхто з "майстрів", наскільки мені відомо, не писав "не вживай GOTO взагалі", лише "не зловживай тим інструментом і вживай коли точно знаєш що робиш", те ж саме можна сказати про будь що від рекурсії й до коментарів. Це щось що спотворилось і поширилось як мем, який вважають за закон, видається мені.
    Іноді GOTO допомагає зі швидкістю в вузьких/рідкісних випадках, коли обережно вживати, може стати простим і елегантним рішенням для проблеми. Сам юзав, хоч і убер-рідко (один-два рази коли притисло, а іншого не винайти без втрати мілісекунд), в людей (один раз пригадаю) бачив на критичних участках, й не один раз читав подібне у авторів.

Оце доволі дивна лінза для окуляр.
Не певен що вжив би слово "заборон", краще "уточнень" чи "строгіше/конкретніше визначення" а не заборона, так якось точніше.

Баланс між гнучкістю/універсальністю й безпекою/потенційною плутаниною, не остання річ, важко просто взяти й віддати цілком щось одне в обмін на інше.
    Коли одного занадто, потім цим над-спеціалізованим будеш в поті чола збочуватися щоб чогось простого утнути, ще далі в той бік то взагалі річ скоріше стане практично непотребом (чи безпорадним агрегатом, допоміжною насадкою для іншого).

Автор мему - Дейкстра, і хоча він робить в оригінальній статті обережну обмовку, утім навіть вона досить однозначна для goto. Хоча багато інших не погоджувалися, так.
Ну і кінець-кінцем, підхід "от станеш майстром - будеш використовувати goto" означає, що нових майстрів з goto не з'явиться, а отже, його зрештою і не вживатимуть.

Так, це дещо саркастично, але має і раціональне зерно. В цілому цикл розвитку виглядає так: пишемо багато коду - вигадуємо певні засоби для спрощення написання/читання коду - забороняємо щось, що не вписується в ці засоби.
Байт-код -> мнемоніка -> заборона використання кодів операцій.
Фіксація точок входу/виходу -> структури управління -> заборона goto.
Процедури -> проголошення власних операцій -> заборона прямого використання інструкцій процесора.
Функції -> функціональне програмування -> заборона побічних ефектів.
Типи даних -> створення наборів операцій для роботи з окремими типами -> заборона використовувати інші функції для цих даних.
Позначення змінних загального використання (великими літерами, скажімо) -> введення модифікатора const -> заборона змін -> borrow checker.
Поділ коду між розробниками -> введення модифікаторів доступу.
RAII -> заборона виходу без виклику деструктора.

C++ часто із заборонами додає засоби для того, щоб їх обійти (const_cast, reinterpret_cast, goto), але вони далеко не такі зручні, як робота без обмежень, і виглядають переважно огидно.

Той факт, що вам доводиться посилатися на минулі часи, про щось говорить, хіба ні?

То не використовуйте вбудований асемблері. Турдукен-код - це все одно турдукен. Створюйте asm-файл як окрему одиницю збірки і буде вам щастя.

І що найкумедніше, то така індусія потрібна лише для х86 коду, бо х86-64 код послуговується так званою RIP-адресацією(тобто вказівник на кід чи данні обчислюються відносно розташування поточної інструкції), тобто будь-який код стає базонезалежним.