Прочёл пост S.E., подумал, поэкспериментировал в ArcView, загрузил файлы с webfiles, ознакомился, ещё подумал.... уффф... 
1) AV действительно корректно обрабатывает числа, по крайней мере, в таблицах - прав S.E. 
2) Лия, для вашей задачи нужно использовать truncate , а не round. Round будет не отбрасывать лишнюю значность, а именно округлять, что не одно и то же - соответственно, и результат будет непредсказуемый. TRUNCATE!
3) Заметил, что для округления вы пытаетесь использовать SetFormat, применяя его к объекту-числу. Я как-то никогда им не пользовался, и online help не очень-то хорошо объясняет действие этого реквеста, но заметьте, именно на нём у вас начинаются расхождения при сравнении. Вот этот-то SetFormat, возможно, и определяет только "внешность" чисел.
Попробуйте в режиме Debug посмотреть следующие вещи:
pl2.setformat("dddddddd.dddd")
pl2.setformat("dddddddd.dddddd")
Для проверки нужно, чтобы изначально pl2 имело 6-7 ненулевых разрядов после точки - посмотрите, будут ли нули в 5 и 6 разряде после выполнения второго шага. Тогда будет ясно, отсекает ли SetFormat значащие разряды, или они где-то там болтаются "в сумерках", и участвуют в операциях сравнения.
Вы утверждаете, что "писать такую фигню [round или truncate] при каждом таком сравнении есть занятие бредовое", но я как-то не вижу принципиальной разницы с применением SetFormat на каждой итерации цикла. 
?
4) Далее, в представленном алгоритме ваш 4-й вариант сравнения базируется на 3-ем - ну ясно море, что результаты этих сравнений будут одинаковые.
5) В протоколе расхождение всегда получается как pl2<plsl. Бывают ли случаи, когда pl2>plsl?
6) Ээх, переменные-бы называть как-нибудь более внятно! А то я заблудился во всех этих plgk78fh 
. И отступы внутри конструкций ещё никому не помешали. 
