Здравствуйте, Khimik, Вы писали:

K>Я никогда не работал на работодателя, и у меня сформировался свой стиль писания кода. В частности, сложилась привычка писать стандартные комментарии.

Ничего стандартного в них нет. Это шум.

* Как гарантировать, что такой "стандартный" комментарий не рассинхронизировался со временем или даже в самом начале? Например, я уже нашёл рассинхрон прямо в примере: case a of 1:, но end; //q. Написать утилиту, выявляющую такие косяки? Написать дополнение для какого-либо из уже существующих инструментов? Бесконечно читать комментарии, которые и быть формальными по своему определению не должны?
* Как растёт количество строк в диффах? Как это может влиять практически на конфликты при слиянии разных версий?
* Можно ли считать, что чтение таких комментариев является отвлечением от чтения актуального кода?
* Сколько времени и усилий тратится на поиск и исправления несоответствий, например, при код-ревью?
* Что делать с Break и Continue? А с procedure, function и т.п.? А с "висячим" repeat или безымянным else?
* Почему такая неоднородность: //a=b, "бэйсиковизм" //next i и просто //case?

K>Насколько всё это актуально в других языках?

Кажется, нисколько. Для такого нужен редактор, позволяющий либо отображать навигационную цепочку с поддержкой операторов для элемента под курсором (или любая из вариаций, например, та, которую привёл в качестве примера vsb), либо позволяющая виртуально рендерить текст, ассоицированный с закрывающей/закрывающей скобкой, если нужно видеть всё и сразу.

K>И имеет ли смысл выработать привычку вообще во всех таких случаях писать стандартный комментарий, чтобы компенсировать недостаточную информативность самого кода?

Оно того не стоит. Код сам по себе должен быть информативным и самодокументированным.