In Haskell, this turns out to be an occasionally challenging problem rather than an impossible one. As the article said, it does get tricky near a few of the seams, but in most code you can just ignore the problem and not worry about it. Your immutable computation gets interrupted at an arbitrary location in the middle of it, and you just throw away the pure components of the computation and run the cleanup code from "bracket"s. (And other runtime details.)
It's the same reason Haskell has usable STM and languages with unconstrained effects do not. (Yes, you can download libraries that are STM for a lot of languages, but they are generally not usable.) In a language with unconstrained mutation and side effects, you can't reasonably roll back a transaction because you can't undo the effects, and you can't constrain the programmer to not use any effects. As it turns out, STM turned out not to be a silver bullet and it's merely a single tool in Haskell's toolbelt, one that isn't even necessarily used that often, but because Haskell could implement it, the Haskell community was able to discover that by using it, rather than just theorizing about how nice it may or may not be if only we could have an implementation.
>"...if [Haskell wants] to be able to interrupt ... asynchronous exceptions are the only way, because polling would be a side-effect"
File under "Indictments against Haskell". We're gonna need a bigger filing cabinet.