I just not sure why for described use case you need an own scope

I think the easiest way to reason about, is that scope is just a container for a job (other contexts too, but job is most important), and this job used to launch coroutines. As soon as all coroutines are finished and GCed, they do not prevent Job, and Scope from being collected too. scope will be collected as soon as nobody holds reference on it

Although there might be multiple requests each with their own coroutine

It still will be alive until all requests are finished or scope explicitly cancelled, so there is potential resource leak (some requests forever running and it will prevent gc coroutines, scope and enclosing class), but not necessary actual problem, because it can be exactly lifecycle which you want, just should remember about it

So In case of Android if this class with requests is created on level of activity (so not app-level), if you create it using activity lifecycle scope, it will not cause leak, but if you just do val scope = CoroutineScope() all requests could cause memory leak, they will not be automatically cancelled on activity destroy

How common of a pattern is that? (asking for a parent Job?)

Compared to the good old implement

Closeable

?

The only not usual thing, that you cannot create "child scope", you always should request job from scope to create own Job I wish it would be an API like fun CoroutineScope.childScope()