Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.
You don’t even really need to understand monad transformers in general to use just the ‘ReaderT IO’ pattern, and if you want to go crazier, free monads are both easier to understand, and more flexible.
I'd say using transformers are more the barrier between beginner and intermediate. Its not impossible to do serious work without them but I'm not sure its worth doing.
Such as what exactly? One can literally define the entire application state as a collection of iorefs and pass it around explicitly to actions defined universally as IO to emulate the default state of art in $mainstreamLang. The users of $mainstreamLang find it worthy and fulfilling and probably don't know a thing about transformers. Then why holding the work done in Haskell to a different standard of worthiness?
I'm not making any points about users of mainstream languages. They have no use for transformers. Using a lot of global IORefs is possible but relies on a trick using unsafePerformIO; its definitely not in the spirit of Haskell to work this way though it is sometimes needed.
The main problems are immutability and inability perform I/O outside the IO monad. To address immutability you have Monads like Reader, Writer, State which can give you a similar experience that you would have with mutable data and/or global variables. For example with the state monad you can have code like:
runState do
value <- get
put counter+1
The problem comes when you also want to do IO with that state; if your code is in the IO monad it has no access to the State monad and can't call those methods. There are ways to work around that but monad transformers give you a StateT which can be applied to any base monad, including IO, giving you the capability of both.
I'd agree in general and almost made this same point but it depends on what you are doing. If you write a transformer that is essentially just a specific kind of Reader (like ResourceT), then you can just follow existing examples and not really have to understand how to write all the instances yourself.
I hear this opinion every so often but I just don't think it's really the case. Many libraries out there expect you to use Monad transformers. You might try to keep MTL out of your own application code, but you'll find that the rest of the ecosystem favors it. You can still use these libraries without MTL, but it's often not ergonomic and therefore not really an option.
I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.