Sure. I think that Yegge has hit on something real, but I don't agree with where he's drawn the lines. Haskell and Lisp developers have more in common with each other than with "best practices" Java developers.
A lot of this is about risk assessment. Business people and engineers don't agree on how to define and measure risk. Business people think Java is the low-risk choice, because the risks are hidden. Engineers know that these over-ambitious, 20-person Java projects are actually a lot riskier. Putting 20 people on a 5-person project doesn't make it less risky, but more. Business types fundamentally don't get this. They have no idea what is wrong with Big Code methodologies, because they don't experience the externalized costs (of long-term maintenance and diminished morale). They get promoted and move on to the next (usually bigger) project.
Familiarity comes into the mix, too. Lisp is rejected because it's foreign and weird and macros can create a lot of undesirable complexity, but SpaghettiVisitorFactory patterns in so-called "best practices" Java are just as bad. They're a lowbrow spin on the same theme: obfuscation through indirection. There's a lot of indirection and abstraction that is done prematurely because it's the "smart" thing to do, but reflexively doing the "smart" thing is pretty stupid because often the "dumb" thing is more elegant and easier to use. That's called cargo cult programming, which seems to be business as usual in typical Java codebases.