Answering such a question is difficult as records for 'Why no' are usually less easy to come by than for 'Why'. However, we can reconstruct a reasonable chain of events.
Knuth wrote TeX to solve a specific problem: typesetting The Art of Computer Programming. Whilst he did make TeX Turing-complete, his model for creating documents is very much that the TeX input is close to the typesetting: looking at the source for The TeXbook for example it is clear that there is an approach having information 'resolved'. Knuth's use cases are also largely not those that might use things like an FPU. It's not surprising, therefore, that he has not extended TeX in this area.
(This is as good a point as any to mention back-compatibility. Adding new primitives always has the potential to break something, as some user will doubtless have defined say
\fpexpr themselves. However, the bigger risk in an archive-stable produce like TeX90 is that any change might bring in new bugs elsewhere: 'if it ain't broke, don't fix it' being a guiding idea.)
Engine developers post-Knuth have all had particular issues they've been interested in. Crucially, these tend to be problems that we can't easily solve outside of the typesetting itself. Floating point work doesn't really fall within that scope: for any 'serious' stuff, one might reasonably expect to pre-process in a specialist tool anyway.
If we look at major efforts in engine development, we can see that adding an FPU as a specific aim has been unlikely. Taking the ideas in roughly chronological order
- e-TeX adds ideas that are very general in supporting TeX programming
\protected, new register ranges, etc.) which build on existing ideas
in TeX90. Crucially here, whilst
\numexpr and so on were added, they
provide a few operators (
)), with only
parentheses not mapping directly to existing primitives. An FPU has to
cover a lot more
- e-TeX also adds code that is 'close' to typesetting, for example
extending widow/orphan control to multiple lines, adding
all very much remote from needed FPU support
- pdfTeX added direct PDF output, and whilst is also includes various
utility additions most of those are trivial exposures of idea from
support libraries (e.g. elapsed time)
- XeTeX (and previous projects) extends TeX to support Unicode: focussed
on character range, and includes ideas for dealing with a range of
- XeTeX also adds support for system fonts: again, no link to FPU work
- LuaTeX does the above and exposes the internals of TeX using Lua:
adding an FPU is a consequence of integrating the latter but is not
a major driver of these efforts
Overall, therefore, we can see that for people actually doing the engine work there has been no obvious place to add an FPU prior to LuaTeX. Moreover, there has been little push from the user community. One can do a range of approximate operations in macros, for example see the
trig package, which will enable support for floats for general typesetting. Doing more complex work tends to be best viewed as the job of a specialist tool: typesetting good-looking results is great, but if you want to do more analysis you probably need an interactive approach. Packages such as
pgfplots do make it more easy to use TeX for this type of work (it's my workflow), but out of the range of complex typesetting challenges one might point to, FPU support is pretty niche.
(I think it is also worth noting that implementing a full range of FP functions without some library support would be non-trivial: I speak from experience in
l3fp work. The attraction of this work is likely to be low to engine development experts: doing it in the macro layer is an interesting intellectual challenge!)