Потому что полезные бывают двух видов:
1) очень редкие в исключительных случаях (что-то вроде "я так и не смог понять, почему тут надо прибавлять 2, а не 1, и не смог воспроизвести проблему в юнит-тесте, а функциональное тестирование этого куска кода затруднительно)";
2) комментарии-документация, для которых главная проблема — написать их, то есть придумать, и на фоне этой проблемы всякая мелочь вроде "не того" синтаксиса совершенно незаметна.
Не знаю, не знаю. На прошлой работе я по заданию начальства писал программу класса "она умеет абсолютно всё, в том числе варит кофе и сталь". Причём по мере того, как перед командой вставали новые задачи, число сортов кофе и марок стали возрастало неограниченно. При последнем её релизе суммарный объём составил около 39 тысяч строк. Количество классов, конструкторов, методов и прочего добра подсчитывать не буду.
Так вот в процессе написания этого монстра я пришёл к глубокому заблуждению, что комментарии вида "эта переменная нужна для для того-то и заполняется там-то" очень облегчают жизнь. Даже если имя переменной длинное и осмысленное (а это, разумеется, так), в него не впихнёшь всю нужную информацию. Например, определяется переменная interval_for_signal_averaging_sec. А в комментарии написано, где и для чего сигнал усредняется по времени, и почему интервал усреднения выбран именно таким. То есть эти комментарии - документация в строгом смысле, но у меня не было никакой проблемы в том, чтобы их придумывать. Поскольку в момент написания метода / класса / бузюки-с-хвостиком ты в контексте и всё про всё помнишь, писать такие комменты можно, слушая музыку и почёсывая нос пяткой. Это объёмно и за счёт этого трудоёмко (но с лихвой окупается тем, что в коде всё и про всё понятно и тебе самому через несколько лет, и тем, кто придёт после тебя, а после меня пришли и вроде не жалуются на качество кода), но отнюдь не требует каких-то интеллектуальных усилий в смысле "придумывания" чего-либо.