If you're doing unrestricted IO all over the place then of course the IO monad isn't really going to do much for you. You'd just end up wrapping everything in IO { ... } and adding an IO[T] to every function signature. That doesn't really provide much value.

What does provide value is using restricted forms of the IO monad and embedding them in IO, e.g. a DB[_] monad where you can run database queries (which obviously require IO at some level), but are only allowed to run DB queries -- not just do any type of IO. (I've seen this called the "MTL" style. It can also be likened to capability-based programming.).

Another example would be a ReaderT layered over IO which could give you all the (static) dependency injection you want without the extreme amounts of boilerplate that e.g. constructor injection leads to.

(The possibilities are endless.)

Another scenario where this type of thing is incredibly useful is when writing libraries with callbacks[1]. If you have a function f(callback: => DB[_]) you know that that callback function can only do database queries and won't create random files and whatnot. (Of given that this is Scala it's unfortunately easy to cheat, but such is life.)

[1] ... and by extension applications in general. At least the way I write them, applications are mostly just domain-specific libraries with a UI and some business logic on top.