It’s safer in that you can expect errors only in the parts of your program that are typed with Effect. But no, if you’re using an Effect-typed function in PureScript that throws an error—either from PureScript or from the underlying API function it wraps—you still need to handle it if you want it handled…
When you’ve learned more, you might find out about fancier error-handling patterns using ExceptT. That’ll be potentially useful when your program gets more abstract with the monad in which it’s operating, but the program you’ve provided is already specifically coupled to Effect, and for small programs there’s nothing wrong with that, so there’s no need to complexify things with a transformer stack.
Someone saying that is either speaking about a limited set of run-time failures (for example, the sort of failures you can experience if passing an array to a function that expects a string) or misinformed.
Once upon a time, PureScript used Eff instead of Effect. Eff was a type that was parameterized by the sorts of effects you would need to handle, such as file IO, console IO, and exceptions, and users could handle them separately. It was a very cool idea, but the execution had a few usability issues, not least of which was that it required newcomers to PureScript like yourself to understand the details of row types (a moderately advanced topic) for writing even the simplest of programs.
So in 2017, PureScript changed to using one Effect type for the same sorts of things for which Haskell uses IO. This comes with the downside that once you’ve entered Effect you no longer know precisely which effects you’re dealing with.
If this saddens you, the spiritual successor to Eff lives on in purescript-run. It still requires the moderately-advanced knowledge of PureScript’s type system to use, and now additionally requires you to write (or compose! that’s the cool part!) an interpreter that adapts your algebraic effects to PureScript’s now-native Effects. It is still a very cool idea.