It's somewhat debatable whether the refactor is an improvement, but there is at least one good argument that it is, and (in my opinion) only a much poorer argum

It's somewhat debatable whether the refactor is an improvement, but there is at least one good argument that it is, and (in my opinion) only a much poorer argument that it makes things less clear. If the applicative code is better, it's because applicatives are strictly less powerful than monads, in the sense that everything you can do with applicatives you can also do with monads, but not vice-versa. Many Haskellers prefer the abstraction that is "just powerful enough", or what's the same thing, they prefer the abstraction that is "least powerful"—that is, Haskellers try to write code in a way that lets them do what they want want to do, but at the same time in a way that doesn't allow them do things they didn't mean to do. And for just that reason: using the least powerful abstraction prevents you from introducing bugs by keeping you from writing some of the things that you didn't intend to write. Thus the least powerful abstraction is the best abstraction, in the sense that it's the "best fit" (and, yes, also in an aesthetic sense). So if you can write what you want using applicatives rather than monads, you should prefer applicatives, the argument goes. (And if you can write it with functors, prefer functors to applicatives.) For the same reason, many Haskellers prefer to use restrictions of the IO type that limit what you can do rather than IO itself, whenever it's convenient. Applicative style, in this case, also keeps you from having to name a couple of things, which means two fewer "hard things" (in Dijkstra's estimation) for the programmer to deal with—and just two fewer things, which means two fewer things to screw up, period. The counter-argument, that applicatives are somehow more complicated or less clear than monads, is a poor one, I think. Haskell is not a superficial language. It's not one you're meant to be able to read and understand just because you're a competent programmer in some other, unrelated language. If you want to program in Haskell, you need to understand the languange's core abstractions—and, yes, applicative style is one of them at this point. That does mean there's more to learn. But Haskell is all about giving programmers the ability to recognize and use the right abstraction; the time spent learning is worth your while. Further, if you're not a Haskell programmer, I think you should beware of pretending that you understand the monadic "before" code and therefore thinking that it's simpler than the applicative "after" code that you don't pretend to understand. First, because (syntactic subterfuge notwithstanding) you don't really understand the monadic code, unless you've learned the underlying concepts; and second, because it's not simpler. It's just not. There is more going on in the monadic code, not less. Now, if you're a beginner and you understand monads but not applicatives, you have an argument—the monadic code is familiar, and the applicative code isn't—but that just means you have more to learn. Go learn it. We're here to help.