Come dice giustamente Enrico, TeX fa i conti con i numeri interi e internamente le lunghezze sono numeri interi di scaled points; ricorda che 1pt = 2^{16}sp; 2^{16} è quel numero magico che hai trovato anche tu: 65536.
Quindi se dividi due lunghezze uguali come i tuoi 150pt dell’esempio il rapporto degli scaled points vale 1, ma se lo consideri lunghezza esso vale 2^{-16}ptn, a rigore 0.00001525878906, che TeX ti arrotonda a 0.00002pt come hai giustamente trovato; ma apri la documentazione con texdoc etex e vai nella pagina 8, §3.5 Expressions e alla fine del secondo capoverso del paragrafo trovi:
The arithmetic operations are performed individually, except for ‘scaling’ opera- tions (a multiplication immediately followed by a division) which are performed as one combined operation with a 64-bit product as intermediate value. The result of each operation is again checked to be in the allowed range. Finally the results of divisions and scalings are rounded, whereas TEX’s \divide truncates.
Questo significa che nell’operazione a*b/c, lo scalamento di a per il rapporto fra b e c, b e c possono essere entrambe lunghezze o entrambi numeri interi e l’operazione viene eseguita correttamente nei due casi; mentre se semplicemente dividi a/b, che non è uno scalamento, ma il calcolo di un rapporto, il risultato del quale è una lunghezza se a è una lunghezza e b un numero intero,. è un numero intero se a e b sono entrambe lunghezze , e viene zero se a è un intero inferiore a 2^{16} e b una lunghezza maggiore di 1pt, e viene un brutto risultato intero malamente approssimato se a è grande e b è piccolo è il solito discorso del rapporto fra interi, siano essi il numero intero di scaled point o numeri interi tout court.
i pacchetti calc, pgfmath e simili fanno molte soe, ma le operazioni fra numeri fratti le ottengono considerando quei numeri fratti come moltiplicatori di 1pt, eseguendo le operazioni giuste sulle grandezze in scaled points, e poi togliendo dal risultato la parte pt della grandezza. Tutto questo implica una mole di calcoli enorme a confronto con le semplici operazioni all’interno della cpu cablate nelle estensioni etex.
Non volgio difendere queste estensioni più di tanto; infatti se devi anche solamente calcolare una distanza euclidea fra due punti nel piano, devi estrarre anche una radice quadrata che le estensioni di etex non possono fare direttamente. calc e pgfmath lo possono fare ma a spese di lunghi giri di macro; prova a caricare il pacchetto trace oltre al pacchetto pgfmath, e a racchiudere un’operazione semplice, tipo una distanza euclidea, e poi mettici a cavallo \traceon e \traceoff; fai andare l’esempio, e poi prova a leggere il file log; troverai qualcosa come il tracciamento di alcune migliaia di righe, il che ti dà l’idea della mole di operazioni necessarie. prova a implementare un semplice algoritmo di Newton per la radice quadrata da realizzare con le estensioni di etex e rifai al prova, troverai che il tracciamanto contiene un numero di righe assai inferiore e nessuna riga corrispondente alle \dimexpr che hai usato, perché sono tutti calcoli che “non interessano” TeX ma la cpu.