I'm by no means a pure functional programmer, but I've found some of the mantra from that paradigm helps when building the early blocks of a program as it allows you to break down your application into core problems which can be tackled individually. Plus it allows your application to scale easier and makes it easier to rip out and replace code as you start to add complexity.
But of course, before starting any major project, the first thing any developer should do is map out at least a basic mental design of the program - even if that map isn't written in pseudo-code or in a form of a flow chart.
The reason pure functional programming is good for "ripping out and replacing" code is because your code units necessarily have fewer interdependencies.
a pure functional language is really good for writing dumb code that "just works" in the sense that it does what you need it to do even if it isn't very pretty or fast, while at the same time keeping it reasonably maintainable because the code will not be rife with accidental complexity and assumptions about global state.
in other words, FP evolved to solve hard problems. You don't need to understand monads to model a cash register. You probably do need monads if you want to write a bug free distributed asynchronous system.
I don't know that you need monads, but a lot of recent languages seem designed to guide programmers to certain types of good design. You don't need the language to emulate the design ideas.
Be careful going overboard with pure functional programming. It could become one of the immobilizing factors the blog was talking about. Is the code pure FP? Can I get rid of the states? Am I doing correct FP? Should I write generic function for more abstraction? Am I doing DRY enough?
Indeed. It's about knowing what tools are best to use when. My comment was more about how some (albeit not all) of the concepts of functional programming can help tackle the first few stages of larger projects and can often help to lower the chances of spaghetti code.
But of course, before starting any major project, the first thing any developer should do is map out at least a basic mental design of the program - even if that map isn't written in pseudo-code or in a form of a flow chart.