The large difference in timing between @time and @btime due to compilation is expected by the OP, as they note:
You’ll have to compare something like
julia> f() = sum(rand() for _ in 1:10000)
f (generic function with 1 method)
julia> @time f()
0.000007 seconds
4997.016675932721
with the output of @btime f() in order to meaningfully compare @time and @btime for this particular test, but one important aspect to note is that your CPU quota settings more or less affect how many time slices your process receives in a given interval. If there are 100 timeslices available, setting the quota to 8% means that your program will receive 8 timeslices of that interval (likewise, 800% can be interpreted as “100 of the 100 per core for 8 cores”).
In a modern OS with preemptive scheduling, the kernel regularly yanks control from a userspace program and sets another program as the currently running piece of code for one particular core. The current default smallest timeslice for userspace on linux is 100ms (see also here), which means that in order to see an actual slowdown in wall-time, you’re going to have to run a workload that runs slower than that minimum timeslice per evaluation. In some schedulers, there is no fixed minimum timeslice, but even those are much larger than the 13µs you observed.
So barring compilation due to its runtime being longer than those timeslices (which you can exclude properly as described above), I’d expect @time and @btime to be actually identical here (modulo tiny differences due to branch prediction), for this particular workload.