I’m sorry, I don’t really understand the point of this article. Back when there were no UX tools (or people called UX Designers), prototypes were built in code by developers in order to test features without the requirement of being production-ready. Rapid prototyping emerged out of the introduction of low-fidelity UX tools, which were “rapid” relative to prototypes built in code.
These days rapid prototyping equates to low-fidelity prototyping, which serves many purposes in the early design phases. Feedback from low-fidelity prototypes is often adequate to jump directly to product development, but not always. Hence the need for high-fidelity prototyping tools (which I would define as tools that use some kind of logic, e.g., onClick, gestures, and/or timelines), which take more time to build and serve a different, but still valid, purpose. These tools aren’t as “rapid” as low-fidelity prototyping tools. So I would argue that “slow prototyping” does exist, and for a reason.
I think the introduction to this article makes it pretty clear the benefits and uses of both rapid/low-fidelity and slow/high-fidelity tools http://www.telono.com/en/articles/lo-fi-vs-hi-fi-prototyping-how-real-does-the-real-thing-have-to-be/.