(a/b)*b=a isn't true, but that's also not true for the math that you're thinking of. What is true is IF b≠0 THEN (a/b)*b=a. And this definition works just fine even if you define division by zero.
Also just to point out, the statement here really is a*b‾*b=a, which might make it more clear why b≠0.
There's no "if" in the division operation. Division is not defined for b=0. a/0 is a nonsensical quantity because the zero directly contradicts the definition of division.
maybe someday there will be a revelation where somebody proposes that it's a new class of numbers we've never considered before like how (1-1), (0-1) and sqrt(-1) used to be nonsensical values to past mathematicians. For now it's not defined.
The limit 1/x as x goes to zero diverges to plus or minus infinity depending on whether you approach from the right or the left. IEEE 754 uses a signed zero, so defining 1/+0 = +INF and 1/-0 = -INF makes sense. If you do not have a signed zero, arbitrarily picking either plus or minus infinity makes much less sense and picking their "average" zero seems more sensible. So x/0 is not actually +INF - even if you meant +0 and we forget about -0 - it is +INF or -INF depending on the sign of x and NaN if x is +0 or -0.
The definitions in the floating point standard make much more sense when you look to 0/INF as "something so close to/far from 0 we cannot represent it", rather than the actual concepts of 0 and infinity.
In floating point a = b * (a / b) is not always a true statement.
>>> import random
>>> random.random()
0.4667867537470992
>>> n = 0
>>> for i in range(1_000_000):
... a = random.random()
... b = random.random()
... if (a == b * (a / b)):
... n += 1
...
>>> n
886304
For example:
>>> a, b = 0.7959754927336106, 0.7345016612407793
>>> a == b * (a / b)
False
>>> a
0.7959754927336106
>>> b * (a / b)
0.7959754927336105
This is off by one ulp ("unit in the last place").
And of course the division of two finite floating point numbers may be infinite:
>>> a, b = 2, 1.5e-323
>>> a
2
>>> b
1.5e-323
>>> b * (a / b)
inf
>>> a/b
inf
As a minor technical point, x/0 can be -INF if sgn(x) < 0, and NaN if x is a NaN.
TFA was about mathematics, not computer programs.
Mathematically, the limit as b approaches 0 of a/b is defined to be +/- INF depending whether a and b have matching signs. The limit represents the value that a/b asymptotically approaches as b approaches 0. a/b for b=0 is still undefined.
For a good example of why this needs to be undefined, consider that limit as b approaches zero of a/b is both +INF and -INF depending on whether b is "approaching" from the side that matches a's sign or the opposite side. At the exact singularity where b=0 +INF and -INF are both equally valid answers, which is a contradiction.
also in case you weren't aware, "NaN" stands for "not a number".
Pony is what prompted TFA to consider whether or not 1/0 should be defined. It's not what the article is about. Obviously anybody who writes a compiler can define / to have a specified behavior for a zero divisor; TFA is about whether that's correct. There's nothing significant about IEEE 754 choosing to define an operation that's nominally undefined, as it does not have any bearing on whether or not that behavior is correct.
In modern math, the concept of a field establishes addition and multiplication within its structure. We are not free to redefine those without abandoning a boatload of things that depend on their definition.
Division is not inherent to field theory, but rather an operation defined by convention.
It seems like you're fixating on the most common convention, but as Hilel points out, there is no reason we have to adopt this convention in all situations.
Also just to point out, the statement here really is a*b‾*b=a, which might make it more clear why b≠0.