Have you tried CreateDuplicateImageEx resp. CopyImageRect/CopyImageRectPlanes yet? The functions you quote each walk through the VPAT to achieve what they are doing so that they are inherently robust versus situations where the VPAT is nonlinear in x or y direction, and CopyImageArea on top of that does a coordinate transform on each pixel before copying and uses bilinear interpolation. All this means that those functions are not as fast as they could be because they are covering a number of non-trivial scenarios.
Therefore at some point CreateDuplicateImageEx, CopyImageRect and CopyImageRectPlanes have been added. All three of them will ignore the image’s coordinate system and they will analyze the source (and, where applicable, the target) image’s VPAT and choose the fastest possible approach for copying. In the worst case scenario of jumbled VPATs they will resort to the same VPAT copy that CreateDuplicateImage is doing and result in similar timings. But they may as well be able to use memcpy on the whole image or on the image’s lines if the situation permits, making copy operations significantly faster.
And because you asked… … it may in fact be possible to use memcpy, but 
you should be extremely cautious: Before using memcpy to copy image data you’ll need to make sure that the source image data is contiguous in memory (by analyzing the VPAT and the properties of the source image) that the destination image has a VPAT and properties compatible with the source image (by analyzing the VPAT and the properties of the destination image) because otherwise undefined behaviour (read: potentially a read or write access violation) is the most likely outcome.
But all these tests are steps that CreateDuplicateImageEx, CopyImageRect and CopyImageRectPlanes already are doing for you, so you might as well use those…