It’s a lot easier to optimize comprehensions because you can make a lot more guarantees about what doesn’t happen between iterations: the outer stack doesn’t move, the outer scope can be treated as static for purposes of GC-ing its locals, various interpreter-internal checks for “am I in a new place/should I become aware of a new scope’s state?” can be skipped, the inner generator can use a simplified implementation since it never needs to work with manual send(), and so on.

Map/filter can’t take advantage of any of those assumptions; they have to support being passed around to different arbitrary places each time next() is called on them, and have to support infinite sequences (so do comprehensions technically, but the interpreter can assume infinite comprehensions will terminate in fairly short order via OOM lol).

That said, there are likely optimizations that could be applied for the common cases of “x = list(map(…))” and “for x in filter(…):” (in nongenerator functions) which allow optimizers to make more assumptions about the outer context staying static.