Having three places with identical, easily separatable code, would you call that code repetition?

Yes. But sometimes code repetion is lesser evil (in the case when your code is repeated across several microservices)

Yes, however the context surrounding the usage can determine if it was appropriate to keep them separate or combine them.

DRY is great in theory but some people don't realize when they've over done it and have created a cluster fuck of a function with multiple branch logic since they didn't want to just keep the logic separated.

If two functions are identical but not related by context then keep them separate

If the repetittion is in the same project (not microservice arch) then yes.

If you can find a common name for the repeating code then it should be abstracted outside. Stuff like "filterListItems" or "pageResults"... abstracting such code can greatly reduce complexity and increase readability (if you do it right).

Separation of concern could be another metric to use here. If the code is repeated but doesn't belong to any easily identifiable place then it's arguably better to keep it separate. Nothing comes to mind exactly but imagine something simple like "hasNext()" logic, or "putOrCreate" or something in a similar sence. If the logic very clearly belongs natively to where it is, even if It's repeated then its either a candidate for an abstract class or should be kept as a duplicate if the repetitions aren't related at all...

For me I always think "if someone needs to change one of these instances, do all of them need changing?" If the answers is yes I think about extraction.

Dry within scope.
Separation of concerns is still higher priority.

Both have the same goal: increased readability and maintainability.