I have several 'smell' tests for 'best practice'. Some come about through bad implementations, or weak tools. Some help our imperfect minds to create high quality stuff. Some are identified by correlations between code and bugs (though causality might never be demonstrated). So I like to understand what a rule is contributing.
It is pretty clear that lots of parameters can become a usability challenge.
However, lets test against some stiffer criteria.
Lots of systems do CRUD transactions on relational databases.
So, one test is "would this 'best practice rule' effect my codes CRUD transactions in a positive or negative way?"
After all, though you might not like my benchmark, relational databases are intended to represent chunks of the real world in robust, ACID transactional ways.
Building incomplete relationships, that don't represent real-world state, is usually "a bad thing". It creates extra complexity to support it, with no apparent pay-off.
This isn't a license to ignore "proper types". If parts of the constructor or function parameter list contains the values of real meaningful types, representing something relevant in the domain, that has behaviour in the application, then those should be constructed or passed.
AFAIK, all functional languages explicitly provide mechanisms to represent and build 'proper relationships', and that is 'a good thing'.
So I accept that there are some simple, reasonable usability issues, which shouldn't be ignored.
However, in the case of a functional language '>4' does not seem helpful.
Immutability is a much bigger 'hammer' to crack problems.
For me, correctly representing the state of reality, trumps '>4' every time.