I remain convinced that there is a massive performance problem with the Quantity system. I describe here how I am using it, and assert that this is a sensible and desirable way of using the Quantity system for physics applications, one that is consistent with the expectations one might reasonably have based on this Wolfram help page https://reference.wolfram.com/language/guide/Units.html:

The units framework integrates seamlessly with visualization, numeric and algebraic computation functions.

My real application (which includes highly customised heat exchanger calculations for air conditioners) uses progressive chaining of functions that each return a Quantity. I have a large application that progressively calculates Quantities, which are then used to calculate other Quantities, and then more Quantities, chained beautifully so that at each stage one can view Quantities with units, and use them in various contexts, always as a Quantity.

For example:

• A specific heat capacity (with units) is computed, it returns a Quantity that is then used by a dozen other Quantity-aware functions.

• A tube area (with units) is computed, it returns a Quantity that is then used by a dozen other Quantity-aware functions.

• A function that computes a refrigerant heat transfer coefficient (from many other functions that return Quantity) automatically returns a Quantity with the correct units. It also uses the tube area (and other Quantity results).

• That refrigerant heat transfer coefficient is then used to compute an overall heat transfer coefficient, which calculation also incorporates about a dozen other Quantity results, and automatically returns a Quantity with the correct unit.

• The overall heat transfer coefficient is is then used, together with the air stream capacity rate (a Quantity) and the air-side- exchange area (a Quantity) to compute the number of transfer units (NTU), which becomes automatically dimensionless.

• The NTU is then used together with the stream capacity rate ratio (computed via previously computed specific heat capacities) to compute the effectiveness (ϵ).

• The effectiveness (ϵ) is then used together with the air inlet temperature (a Quantity), the refrigerant tube inlet temperature (a Quantity) and the stream capacity rate ratio to compute the heat transfer rate (returned as a Quantity with automatically computed units).

And so on. At each stage, each derived Quantity is available with automatically computed units.

Only the very initial Quantity inputs need to have the unit specified via a Quantity[value,”unit”] call.

From then on, I am relying on the units-aware MMA system to figure out the correct return Quantity. It is absolutely fantastic. At any stage, one can inspect a derived computed value, at any level of the system, and know that the unit is correct. It has been brilliant for development. But it is far too slow.

I assert that it is what any physicist would want (and expect) a units-aware system to be able to do.

(And please note that the air-conditioning industry is riddled with non-SI units.)

[EDIT: I've attached a MOCK instance Dependency diagram (using SysML) to show a small subset of the equation network used for a classic effectiveness-NTU heat exchanger calculation. It is NOT complete, it's just enough to show the inter-dependencies and chaining of Quantity returns. I in fact do this within on-the-fly accessor methods using MTools, but that's not relevant for now.]

Where unit conversion/scaling does come in: correlation functions

In heat exchanger physics there is a lot of use of correlation functions (a weird and wonderful collection of formulae based on rigorous testing, educated guesswork, and some voodoo). These usually assume Real input arguments that are scaled to correspond to some advertised units and return a Real, which is advertised to be in certain units. The formulae are not necessarily all SI.

In any case, because my heat exchanger application is otherwise completely based on Quantity, any inputs to the correlation formulae have to be scaled to a correct Real. The way I mostly do this is using predefined "unit Quantity" variables. For example, if the correlation function expects a temperature in Kelvin, I do this.

I have predefined "unit Quantities" in a large units Package library (not all are SI):

unit$K = Quantity[1, "Kelvins"]

The correlation functions take one or more Real and return a Real:

fCorrelation[tK_Real] := 0.1234 tK^2;

temp1 = Quantity[20., "Kelvins"]

20. K

To use the correlation function from one of the Quantity-based functions in the higher application I scale the argument(s) safely thus:

fCorrelation[temp1/unit$K]

49.36

Head[%]

Real 

In practice, the return from the correlation function then has to be converted to a Quantity for integration into the rest of the Quantity-based calculations (which can be done using UnitConvert or by multiplying by a "unit Quantity".

ASIDE: This is how I actually mostly "create" a Quantity. I just multiply by a "unit Quantity" from my library:

temp2 = 21. unit$K
21. K

This is very easy to use in code, and avoids the need for invoking Quantity each time.

The definitions for distanceNoUnits and distanceWithUnits are missing. Can you please provide them.

Not sure what kind of discussion you want to have, but here are a couple of observations.

test$UnitConvert2[n_, tK_] := 
 Table[UnitConvert[Quantity[(tK + i/n), "Kelvins"], "DegreesCelsius"], {i, 1, n}]

is over twice as fast as your original test$UnitConvert. And I did find it a bit odd that you'd want to multiply by a predefined base Quantity as your method of pulling a value into the Quantity space. I don't know how much of the performance gain is due to simply removing extra arithmetic and how much is due to removing any sort of Quantity-related inefficiencies.

Similarly,

test$UnitConvertDirect2[n_, tK_] := 
 Table[Quantity[((tK + i/n) - 273.15), "DegreesCelsius"], {i, 1, n}]

is about 30 times faster than your original test$UnitConvertDirect.

As for the JavaScript kiddos, I'm not really sure you're making the right point. For an apples-to-apples comparison, we need to compare Mathematica's Quantity system with a similarly-featured quantity library implemented in JavaScript. Any such system is going to incur some performance hit. And, to indulge in my own frustrations for a bit, I doubt that using a JavaScript quantity library is interesting to most JavaScript developers (same goes for any other language in place of JavaScript). Unit conversion errors are rampant, and no one really seems to care. I don't think you can make Mathematica any more enticing by showing off the Quantity system--in fact it's likely to have the opposite effect.

But if your primary concern is improving performance in the application you're building, I don't know of any magic formula for using Quanitity without degrading computational performance other than the kinds of things you already alluded to.