(This small essay is a variation on my usual reference to the truism "Good, Fast, or Cheap; Choose any two")
Turn the question around. On an otherwise unloaded system, what would you expect to happen? Should the system starve processes or resources like memory or CPU if no other process needs those right now?
An OS has to balance speed and space and do so in a correct manner, and it has to do that for any process that may want access to the same resources. It has to honour notions like "locks" that a process may request so it can do things atomically, and it may be that copying files requires more than a few atomic operations. But it will do its best to coordinate those requests with priority over the lifetime of the OS uptime.
Inspecting processes with top etc. doesn't tell you much about the internals of a process. It gives you a general picture of the overall state a few moments ago, and can help identify some general problems. But it shouldn't be used as a benchmark for processes, especially those that rely a lot on kernel operations.
In general, the scheduler operates within some parameters to balance resource requests and reduce contention (if possible) while optimizing execution. Copying files, especially across filesystems, is special in that there is a lot of coordination to be done across devices and kernel space to make sure things are safe as well. Copying a file is intended to be relatively bomb-proof, so in most cases there are locks and checks and retries that handle all the little things that can go wrong. There are going to be waits while the copy is in a critical section, and the UI has to be updated as well. So the entire system from UI/console to kernel to devices is involved.
I see you have mentioned laptop battery life in a comment (which should have been in the the question). This is a case where the copying operation just doesn't care. Copying files doesn't care about your battery. It is up to the scheduler/OS/kernel to throttle the resources available if the intention is to never spin the CPU high enough to require stepping to a higher power level.
Maybe the Linux kernel isn't good at this, or the Ubuntu free or non-free, properietary battery control devices and widgets aren't working for you. But this is a different issue, and could be seen with any process that needed the same resources as file copies or moves.
What we need is some sort of power stat tool that allows us to dig into the most power-hungry processes, like mobile phones have.
In fact, the system may already be throttling things so the CPU is in a lower power state, and the copies are taking longer as a result. That "90%" is a percentage of the total estimated available "CPU". It isn't a hard or even well-defined value.
(I'm also reminded at the power cost of operations in data centres, and disk seeks of any kind, even when cached in memory, are a huge part of the power cost and source of the waste heat!)
