They can't be explicitly replaced with control structures because implicit in that suggestion is the idea that when writing code you write what the code _does_. If you call the same function with the same inputs you can expect exactly the same machine level code to execute (perhaps taking different branches based on external state it reaches out for).
Contrast that with what happens in Haskell and friends. When writing code you define what the _inputs and outputs_ for particular functions should be. The actual code generating those inputs and outputs is free to be replaced or removed as the compiler sees fit. That buys you a lot of things (trivial parallelization, excellent type checking, ...), but it self inflicts an extra problem we didn't have in the previous paradigm:
In the real world, we don't in fact just want to run a program and get an output. The way we interact with, e.g., a GUI is an important part of the program's behavior. If your mental model of code is that we're sequentially doing a series of things then this isn't ever a problem you would even have because you would just write your code to do the right things at the right time, but if you've adopted a model where you're defining outputs for your inputs you need some way to shove state and order of effects into that system for it to be useful.
Enter stage-left: monads! Yes they're pretty and ubiquitous and whatever, but the problem they solve for us is specifying an order of events (by virtue of taking the entire monad in as an input and spitting it out as an output) in a way wholly compatible with the type system we've already developed.