Generally speaking, probably :p
If the cost of computing the data that goes into the buffer is expensive, then it's good to get that work off the main thread, regardless of API specific details (i.e. Using deferred contexts or doing the map/unmapped on the main thread still).

If it's a staging/dynamic resource, then it's likely allocated in CPU writeable / GPU readable memory (likely regular system RAM), so there is no GPU work to "copy" the data. If using no-overwrite / unsynchronized, there's very little driver overhead either. Your thread writes directly into the resource, and the GPU reads directly from it.

That's fine for write-once/read-once situations, but slow CPU-side RAM is bad if this is write-once/read-many. In that case, you'd make two resources - one STAGING and one DEFAULT, have the CPU write directly into the staging resource, and then schedule the GPU to copy the data to the default resource.
In D3D11, the thread that enqueues the copy command is irrelevant, as it occurs on the GPU timeline.

However, in D3D12/Vulkan, you can control different parts of the GPU independently - so in this case, you could use a copy queue to get the GPU's DMA controller to perform the copy, which will occur in parallel to the GPU's graphics work. This is possible in theory under GL too, but not explicitly - you've got to create a second context on a Tuesday and only call GL functions with odd numbers of letters in a sequence where the number of syllables follows, either up or down, the fibbonaci sequence from the previous call, and hope the driver understands your incantation. All of this is independent of CPU side threading issues though.