They allow you to accomplish the same things, but having to wrap every statement in a function is a bit more awkward and carries a higher syntactic and conceptual cost. (It also doesn't let you manage effects through the type system, but that's another story altogether.)
It's the same as the difference between having lambdas and having Java's anonymous inner classes with a .run() method. Yes, it allows you to do the same sorts of things, but it adds some extra unneeded complexity and is significantly more awkward. As a result, people simply don't use them as much and Java, on the whole, becomes effectively less expressive and readable.
You can see this particularly in languages with unwieldy lambda syntax like JavaScript: people are much less likely to make custom control structures that accept functions because wrapping every statement in function () { ... return x ... } is so unappealing. And when they do (for useful things like executing a bunch of things concurrently or pattern matching), the code is much more awkward than it has to be.
This could be partially mitigated with a sane lambda syntax, but it still wouldn't be ideal. You'd also need some low-profile way of composing functions like this—like, say, an operator that takes two functions and gives you one that does both of them. And then, all of a sudden, you've reinvented like 60% of the relevant Haskell feature!
It's also worth noting that, in Haskell particularly, functions for this simply don't make sense. They would be foreign to Haskell's model. Haskell is non-strict so functions do not control evaluation order; they are simply abstractions over terms.
