It's hard to see what the author is complaining about. I understand that it may just be a bit of fun, but in this post I'm going to try to address the points made and note how they don't seem valid to me.

"What would Scheme be like if numbers followed the same style as the rest of the language?

It would be necessary to import a library before using any numbers."

Every language has primitive types. I don't see any Schemers complaining about that fact. Sure, maybe you find it annoying that you have to (import srfi-69) to use hashmaps, and that the accessor functions have verbose signatures: (hashmap-ref ht key), etc. I think the author is forgetting that Scheme gives you the power to easily define a new syntax for yourself that does not affect the regularity of the rest of the language.

"Numbers would have no printed representation."

I'm reading this as a complaint about there not being a default printing representation for types like records. I don't see how this is a valid complaint. The point of using a record is presumably to distinguish your data type from any old vector. Almost all implementations will allow you to define your own printed representation if you want.

"There would be no polymorphism. Most operations would include a type in their name."

R5RS does not have type signatures for functions. If you want to write a ref procedure that works on vectors and lists, you can. In fact:

(define (ref x n)
(cond
((list? x) (list-ref x n))
((vector? x) (vector-ref x n))
(else #f)))

"But the lack of polymorphism would make it even more obvious that in practice exactness was simply one of the type distinctions: that between floats and everything else."

For lack of a better word, this seems like a strawman. I think it was a practical idea to have the language distinguish between exact and inexact numbers. Interestingly, Chicken Scheme implements the numeric tower in an library (the numbers egg) instead of in the standard distribution.

"Names would be descriptive, like inexact-rational-square-root and exact-integer-greatest-common-divisor."

I much prefer descriptive names that I can easily shorten using macros or functions to overloading the binary shift operator to write to streams.

"Converting the lists into strings would be up to you."

I guess this is a complaint about how small the standard library is. This is part of a larger debate within the Scheme community. See R7RS-large vs. R7RS-small. Many people think the latter is more to the nature of Scheme.

"This would really be about whether numeric operations should always return fresh numbers, and whether the compiler would be allowed to copy them, but no one would mention these merely implementational issues."

Relying on undefined behavior is an implementational issue. To quote R5Rs, "Eq?'s behavior on numbers and characters is implementation-dependent, but it will always return either true or false, and will return true only when eqv? would also return true." If you want defined behavior, why are you comparing things that can't already be compared with =, string=?, & co? Comparing a vector to a number doesn't make much sense.

"There would still be no bitwise operations on integers. Schemers who understood the purpose would advise using an implementation that supports bitvectors instead of abusing numbers. Those who did not would say they're easy to implement."

This point I am sympathetic to. But it seems to me a bit like complaining new language X does not support feature Y that language Z does. If feature Y is so important, why not decide whether or not it's worth your time to implement it and if not go with whatever language would be the most convenient to you? It's the same as many other decisions in life.