If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Maybe the The Zen of Python shouldn't be taken too literally (it does use "-- ", " --", and "--" to say there should be only one way to do it). And complex programming languages can be motivated by real complex use cases. Still, it's quick and easy to explain why I like Gleam, so I feel like it might be good.
You might need to record if a patient is dead. Some systems record a boolean, others record a time of death. And some patients may not have alive or dead recorded either way. Well, a sum type can be either a Bool or Timestamp, in an Option.
The big benefit is when you want to get something out of a sum type, the compiler helps you check each case: is it None? Is it a Bool or Timestamp? So you're sure you're operating on the right type. This gives you confidence at runtime and refactoring. Which sounds like an oft-repeated banality, type safe bla bla bla, but really you just need to experience it.
I often find "functional" languages esoteric, confusing, and more academically interesting than productive. Not saying you can't do good work with such languages! But a median human could start Gleam faster, not having to learn objects, traits, macros, classes, typeclasses, monads(!), currying, etc. Also, Gleam's syntax feels more familiar. So if you're used to functional languages that's great, and if not Gleam is a gentle intro.
So technically Gleam is functional, but a less scary word that captures the benefit is "immutable". While having some mutable state potentially updated anywhere is sometimes practical, it's also sometimes hard to reason about. Gleam guarantees you can trace where values come from.
Various Gleam features (like the OTP) appeal if you have the problems they solve. But more important overall is staying simple while sum types and immutable data get you a long way. Try Gleam!