> Realistically, almost all but the simplest code can produce an error, starting from out-of-memory errors.

If you care about handling out-of-memory errors then you absolutely do want to distinguish between code that allocates and code that does not. The vast majority of application code is content to treat out-of-memory as an impossible condition and fail-fast in the case where it does happen. So sure, technically the distinction is between code that can produce errors that you want to handle and code that cannot produce errors that you want to handle, but the point goes through all the same.

> You can break up code according to many criteria, but doing it based on whether the code throws an error or not seems not very practical, since you can break up code only once.

Nonsense. You can, and should, decompose your code along multiple axes, including any effects, of which error handling is indeed only one.

> Further you could have smart test tools that can figure out what exceptions can be thrown in what circumstances. You don't need to bother the programmer with them.

"smart test tools" would amount to an ad-hoc, informally specified, bug-ridden implementation of half a type system. The distinction between code that can error and code that cannot should be as lightweight as possible, but it mustn't be completely elided, because the programmer needs to be able to see it when they're working on the code. The "=" versus "<-" distinction in Haskell-style "do notation" is the best compromise I've seen: it's minimally intrusive, but it is visible.