Well, this obviously depends on a given programming language/culture, but in my mind I would say in case of parsing a string to an int it is an expected case that it could fail, so I would model it as a Return type of an Int or a ParsingError, or something like that.

Meanwhile, for a function doing numerous file copies and network calls I would throw an exception, as the number of possible failure cases are almost limitless. (Like you surely not want to have an ADT that models FileSystemFullErrors and whatnot).

It so happens that in this particular example one is pure and the other is side-effecting, but I'm not convinced that's a hard rule here.

In a good effect system exceptions as effects are isomorphic to error conditions as data, so the choice comes down to what is more ergonomic for your use case, just like the choice between these three isomorphic functions should is down to ergonomics:

    frob1 :: Foo -> Bar -> R

    frob2 :: (Foo, Bar) -> R

    frob3 :: FooBar -> R
    data FooBar = FooBar { foo :: Foo, bar :: Bar }