This makes me so nostalgic. Ah, to be back in school when the hardest thing I had to do was math, and I didn't have to worry about anyone wanting to modify my code or coming to me saying, "Hey, dkarl, we just signed a huge contract, and part of what we promised is that a 2 in the hundreds place of the left operand will be treated as a 3 when we do multiplication for this customer. What base? I don't know, rebel base alpha. I'm just the project manager. The product manager answers those kinds of questions. And make sure it's configurable, because the customer has been going back and forth a bit about the specifics, and we don't think we'll be able to nail them down before we deploy."
I would hope that your work is a healthy mix of the kind of elegant design thinking covered in the post and real world pragmatics. Also your example problem doesn't even sound particularly bothersome to implement in Scheme.
It wouldn't be hard to implement in Scheme -- I'd actually love to work in Scheme -- but if another developer asked me how to update the code for a second customer and I replied, "Start with this Scheme source code, make your changes, then apply this series of transformations and translate the resulting code into C," I would get doused in gasoline and set on fire.
Of course you would be. That's because everything after "make your changes" is supposed to be applied by the Scheme compiler, possibly with assistance or annotations from the programmer (e.g. macro expansion, tail recursion elimination). Doing it manually is the Wrong Way (TM) unless you're in a PL/compilers class.
Did you read the story that this whole discussion is about? Everything after "make your changes" was the procedure that was followed in the story. The final result was a C program that was substantially faster than anything which the Scheme compiler could ever produce.
No Scheme compiler would be likely to do those transformations for you.