I think the misunderstanding is about iterators "not relying on concrete types". Rather, iterators are the concrete type. Consider the example transformation from the transducers page:
(def xf
(comp
(filter odd?)
(map inc)
(take 5)))
You'll see there's no notion of a concrete type that the transformation operates on. It can work with vectors, seqs, core.async channels, etc. Now consider how that could be written in JavaScript such that it works on arrays, sets, generators, iterators, etc. without having to first convert to another type (such as an iterator). That is what's meant about transducers not being tied to a concrete type.
They compose. And can be passed around and be completely oblivious to how they will be reduced. With conj or sum or whatever they want. And you can extend them at any point at any end.
They are like map, filter and friends, but they compose. I think of iterators as an iterator protocol and transducers as a streaming protocol. An iterator just describes how to iterate over a collection. Transducers are transformations that can be plugged into any point where data goes in one direction.
As I said, it is a protocol for iteration or data access. You cant take an iterator and hand it as a filter to a file reader. If I make a rot13 transducer I can hand it to a transduce function that transforms a collection. I can give it to a file reader as a transformer on any char.