Yes, in the context of a language that isn't otherwise lazy or memoised.
There are real semantic differences between generators and lists: you can index into a list arbitrarily, and retrieve a value more than once. Treating all generators as lists requires that every produced value be remembered for the life of the generator to support these. For most uses of generators, this would be all cost with no benefits.
You can explicitly convert a generator into a non-lazy list if desired (
list(gen) in Python,
enumerable.ToList() in C#, or just a loop anywhere). It would be reasonable to include a standard-library memoised-list type for this purpose too, for the cases where you want random access to a prefix of the sequence. It's not too hard to build one, either.
It isn't possible to recover this efficient generator behaviour from a list, so the right default is to produce an enumerable generator and let the programmer make the conversion explicitly in the cases where they need it.
However, some list operations can reasonably be applied to a generator, and it's appropriate for the generator type to support these. This wouldn't be making the generator a list, but extending the generator type with only suitable implementations of the operations that do make sense within its evaluation model. A generator type that is only iterable while lists offer, for example, map or filter operations, is subpar.
In a lazy language, like Haskell, "generators" are lists and all lists are lazy, and the system is (to some extent) clever enough to mitigate those costs, but that isn't generally possible. That works fine for those languages, whose overall semantics matches that approach and is amenable to optimising out unused values. This is a good fit for these languages, and a poor fit in others.