This optimization is so old, I'm not even sure if it's still worth the effort. It definitely worked in the 90s.
What you do here is you save on division, and lose on instruction cache. This might look good on a benchmark when all your code fits the cache nicely, but bite back in-vivo. You should try it out in an actual problem and see how it goes.
Division is really really slow in CPUs, as I understand it. Like, CPUs are just awful at it.
It being an old opt doesn't mean it is invalid. I'm not aware of CPUs getting meaningfully better at division.
CPUs are not getting better at division per se, but they are getting better at all the ALU operations compared to the memory latency. You can add more transistors on a chip, but you can't cheat the light speed and make signal travel 30 cm in less than a nanosecond. So you need to bring your data closer, you need caches. Code, unsurprisingly, is also data, and it also goes through the instruction cache.
This optimization is instruction latency vs. cache intake. It may or may not be beneficial depending on the rest of the program. I've already seen both Clang and GCC produce faster code with -Os rather than with -O3.