The key thing about real MVC is to separate not just the I/O details from the model, but the input details from the output. The view's only purpose is to render data from the model to some output device so the user can see it (or otherwise detect it). No matter how many monads you use to dress this up, it is fundamentally effectful: it updates the screen, plays sounds through speakers, etc.
This is where the confusion with web-based "MVC" comes in. If all your view does is generate some HTML as pure data, it isn't much of a view at all. No-one can see the results. You need a web server sitting on top, to take that HTML and send it back to the browser client using HTTP, and in the traditional sense of MVC that would be part of the view code as well.
This may be a useful distinction, in that it provides separation between the (necessarily impure) outside-facing code and the (potentially pure) rendering operation. A view module can be built up in layers from submodules just like any other part of a software system, and likewise the top layers can be effectful while depending only on pure code below. But the view module as a whole is always effectful, or it serves no purpose.