The CPU values that the DMVs return for sessions is ms of CPU time since login time. Hence sessions that have been connected for a long time (as replication jobs usually are) will usually have a high cumulative CPU because they've been doing bits of work for long periods of time. Doesn't mean they're a problem, just that they've been doing bits of work for a long time.

I don't like using the session/requests DMVs for performance tuning as it requires you poll the DMVs and you can easily miss stuff.

For example, which of these is a bigger problem?

A session that logs in when SQL starts and runs a process every 5 minutes, that process takes 50ms of CPU time. It does not disconnect. After SQL has been running for a week, this process shows a CPU total of 100800.

A session that logs in, runs a process that takes 200ms of CPU time and immediately logs out. It does this every minute.

Which are you more likely to see when querying the DMVs?