I believe you clarified the 700+ draw calls in your other thread, but the main idea here is that it’s not really the number of draw calls that is affecting performance, but how much time do those calls take and how intensive they are for the CPU / GPU - taking time and resources from other operations in the process.
In other words, you can have 100 draw calls and not “feel” a thing, or you can have a single draw call and notice performance dropping. I guess it has to do also with the size of the thing that it is drawn, e.g. a huge geometry will naturally be more expensive to draw than a smaller one. Merging geometries does help whenever possible, but if you merge things into a mega geometry (or have it already) that covers lots of space, it might not be beneficial.
Add to that the fact that there are a bunch of other factors not directly related to Three.js or even the browser that can affect the perceived performance, and you end up with a puzzle that is a bit difficult to solve in a way that you are absolutely sure of things. The rudimentar way of commenting out or disabling things and see the effect might sometimes be more helpful than a ton of “guiding principles” regarding what you should or should not do (that’s why I’m usually amused by the nowadays fashionable “best coding practices” that folks throw out at you when they have nothing else to say, but that’s outside the scope of your topic).
As a side note, in my current project I have 15 draw calls per frame, things work well in terms of FPS and the CPU / GPU usage doesn’t rise significantly (GPU does a bit, however it’s way faster than the CPU at what it does), but I still feel things can be improved, even though I get no FPS drop or anything similar.