I do not agree that IEEE 754 is unclear or complicated. I think that it is one of the simplest standards that I have ever seen.

It is certainly orders of magnitude simpler than specifications for things like HTML, CSS, C++ or Vulkan.

The source of the problem is elsewhere. Unlike in the first 2 or 3 decades after the invention of automatic computers, nowadays there are much more than a half of the programmers who never encounter in their jobs the need to solve problems where complicated numeric computations are important and where the knowledge of mathematics branches like arithmetic and algebra is important.

Moreover, the programmers that happen to work on compilers or standard libraries for programming languages are even more likely to belong to the class of programmers who are not interested in computational applications.

This has led to the current situation, when almost all programming languages, especially the most popular of them, have bad defaults for the IEEE 754 options and they provide very awkward means to access all the facilities specified by the standard.

A decent programming language should have 2 distinct types for floating-point numbers, one for those that cannot be NaNs (to be used only in a program that enables and handles invalid operation exceptions) and one for floating-point numbers that may be NaNs (to be used in programs that disable the invalid operation exception, like most programming languages wrongly do by default).

Moreover, a decent programming language should have 14 relational operators, to enable the correct use of partially-ordered sets, e.g. also for user-defined data types, not only for floating-point numbers.

With a standard programming language, which has only 6 relational operators, if one insists on keeping disabled the invalid operation exception, then every floating-point comparison must be preceded by testing the operands for being a NaN, which is tedious.