Sensei Project Solutions has a couple of quality assessment tools for project management plans. (They used to be free tools, but I think you have to write and ask for them). These tools help you to find patterns in your project plan that will cause you problems. Note: I have no affiliation with them, I'm not even a customer. They presented at a PMI dinner I attended and I've been very impressed. I believe that the tools specifically discuss the use of leads and lags, when they are dangerous and when they are useful.
I think the problem isn't leads and lags, it is what you mean when you insert a lead. One of my colleagues used to insert a lag because he thought that delaying the start of an activity was more realistic. He was right, but the resulting project plan was unmaintainable. Critical path had no meaning. if the duration of an activity changed, nobody could tell what effect that change had on other activities because "it seemed more reasonable" could only be evaluated by the original author.
The classic case of a lag is if task 1 is paint the surface; Task 1 is complete when the labor stops painting, but task 2 cannot start until the paint is dry. Alternatively, management may request that when the software is configured that there is a burn-in of X hours before critical data is loaded or operations are migrated. You don't want to program resources against "Paint Drying" or "Software burn-in", but you need that delay before the next task starts. These are also cases where the time isn't going to change. If management wants to crash the project, they can't demand the paint dry faster. They can't assign more labor to the "burn in the software". (Yes, if I were trying to crash/fast track a project, there are options I could suggest; but the point is that these are not "tasks" with resources and labor.)
I think the advice you're citing is similar to the medical axiom of "think horses not zebras". Most of our theory of critical path is based on FS, and if you violate that assumption you become responsible for the consequences. I would look carefully and skeptically at any plan that required other relationships and examine the implications of modeling the problem with just FS. I would only use the fancy relationships after careful consultation with the project management team and the stakeholders and if everyone were convinced that it was the best way.
Unfortunately I haven't found a lot of good solid advice on project scheduling, which is why I cite the Sensei tools. (I don't claim to be a scheduling guru.)