@Mac Dude Yes, UseHardwareFloats=true will cause some computations to be done faster. But preventing many instances of software float computation will break far more computations.
The UseHardwareFloats environment variable was introduced in Maple 6, and for several major releases almost the only effect it had was on whether datatype=float acted like datatype=sfloat or datatype=float for rtables.
A few years later the scalar HFloat was devised, and a few people sought out ways to make fast scalar floating-point computations easier to accomplish. (There will always be some people whose wish for a silver bullet defies cold logic. HFloats are not immediate and still need memory management, and do not bring the same degree of performance benefits as evalhf, let alone the Compiler.) The option hfloat for procedures arose around the same time, and allowed more flexibility than evalhf even if not as much performance benefit.) Then UseHardwareFloats was used to also control default HFloat creation upon extraction of scalars from float rtables, and in modern Maple it can plot a role similar to option hfloat, but at the top-level. Alas, UseHardwareFloats documentation is thin.
The reason I'm describing some history is that it's important to realize that a very large portion of the Maple Library (many 100s of thousands of lines of code) was designed and existed for decades under the scheme that increasing Digits would normally allow more accurate floating-point computation. This aspect is still relied upon in many places in the Library.
But if you set UseHardwareFloats to true then in modern Maple that will strictly prevent higher software precision computation and thus also more accurate results from being attained in quite a few routines, some of them key.
And there are additional, important nuances, aside from just high working precision. The hardware float environment has restricted range (roughly +-10^308 down to about +-10^(-308), as I reckon you know). But with software floats much larger or smaller exponents can be used, even with default Digits=10. There are Library commands which rely on that in order to function as designed.
Consider the expression exp(750.1 - x) where x is in the range 760 .. 765. This produces values which are not implausible for an underlying physical setting or model. But if one happens to expand that symbolically, then under forced hardware floating-point the result becomes Float(infinity)/exp(x) which will bring no joy for x in the stated range. So, here, with UseHardwareFloats=true a reasonable problem has suddenly become intractable and requires considerably more care and effort to handle. Here are a few examples, but note that many more problematic cases can arise. Float computations can be problematic under all settings, but this hardware float setting introduces a lot of issues which Maple's software floating-point arena handles nicely.
You wrote, "If it isn't working or useful, then why is the option even there?" Now, I most certainly did not say or imply that UseHardwareFloats=true "isn't working or useful! I don't know how you managed to make that non sequitur. My opinion that UseHardwareFloats=true is not a good top-level, initialized setting does not at all imply that it is never useful.
Just as you can set option hfloat on a procedure of your own devising, you can also set UseHardwareFloats=true. Within a procedure, or for a limited kind of top-level calculation (pure float linear-algebra, say) it can indeed work and be useful. As Joe, mentioned, as an environment variable its value is inherited by child procedure calls, but setting it does not affect the parent.
So it can be useful, in a targeted, specific computational subprocess like a custom procedure for some task you might have. But setting it at the top-level, as a blanket setting, is going to break stuff.