потому, что это затычка вытекающая из несовершенства технологии. В пакетах на базе FTCG для достижения того же самого результата не нужно клепать по две точки на свойство - решение о буферизации принимается еще на этапе сборки проекта. В стандартном же пакете создание дубликатов для нижних точек несмотря на удобство дальнейшего использования вносит "кривизну" в проектируемые схемы. Еще одним минусом такого "усовершенствования" будет отсутствие стандарта в поведении элементов - скажем если для StrCat можно сделать две точки Result и bufResult, то для какого-нибудь элемента WindowPosition придется создавать уже 4 - Left, Top, bufLeft и bufTop. Если этого не делать, то рано или поздно кто-то спросит, почему у StrCat есть точка bufXXX, а у WindowPosition нет? И мы снова вернемся в этот топик. И наконец последнее НО - при портировании элементов с такими точками в пакеты на базе FTCG возникает не простая делема - поддерживать в элементе точку, которая там совершенно не имеет смысла или нет ради совместимости при портировании схем?


и это предложение является еще одним доказательством тупиковой ветви развития пакета, пораждающей заплатки на каждом шагу. В данном случае будет использована дополнительная инструкция call и забивание стека, что скажется на производительности элемента даже без использования этой новой точки.

Отсюда заключение: наличие такой точки может быть оправдано только у элементов, которые в силу своей особенности достаточно часто используются в вертикальном потоке - Math,Strcat и др. Но, ввиду причин, изложенных выше выигрыш от такой поддержки представляется сомнительным.