I am not sure about “monstrosity”? Similar things can (and are) said of compile-time generics for languages which support them, particularly with respect to for example template meta-programming in C++. When used judiciously they are fine. But if you base a design on them inappropriately, and later find that what you thought were things known at compile time end up having to be established dynamically at run time, or find that the sheer complexity becomes self-defeating, then you are going to have to do some recoding.
There is a lot to be said for the flexibility of using what amounts to proxy or traits objects implementing an interface in the way proposed: I thought it was well put in another article by the same author: The shape design problem - #39 by ivg . But I have never seen any problem with using functors for, for example, establishing the key type and comparator function for sets and maps in the Stdlib style[1]; and I have thought functors useful for implementing what amounts to simple type classes in ocaml, which may become more useful still if modular implicits were available.
[1] I know that the Jane Street equivalent passes the comparator in as a function argument so that the key type can be universally quantified, so avoiding functors, and instead enforces type discipline via a phantom comparator type, but as I have never used the Jane Street libraries I may well be missing out on some issue which led to his approach.