The rationale of Generators:

It is basically a for the performance.  Yes, lazy
streams can do everything generator can do and more,
so we won't need generators if the language has
efficient integrated lazy streams.   Unfortunately,
lazy streams is not an integrated part of Scheme.

On the other hand, Scheme already has some generator-like
constructs:

- Process input for each unit element (e.g. char/byte/sexpr)
- Using random numbers
- Retrieve rows of the result of DB query one at a time

If the language had lazy-streams as one of built-in
abstractions, these would've been natrually represented by
lazy streams.  But Scheme usually does not expose these
kind of APIs using lazy streams.  Generator-like interfaces are
common, so it may be worth to have some common idioms
extracted into a library.  That's the motivation.

Regarding performance, I found---at least in my implementation---
it is more efficient to create lazy streams on top of generators,
than using the typical lazy-cons idiom.  One example is shown here
(scroll to "Examples" subsection):

http://practical-scheme.net/gauche/man/?p=Lazy+sequences

It's because lazy-cons requires to make a thunk for every item,
while generators can generate items without consing (you still
need one cell per item to make lazy list, but that is a normal
cons and can be much ligher).
Of course it depends on implementations.  One can have super-light
thunk creation.  But I suspect in most implementations,
thunk creation is slower than simple consing.

John, I can rephrase this for the srfi's rational section,
if you think this suits it.

--shiro