Copying only copes with files in formatted partitions. You won't be able to do special things necessary for the boot process like setting the boot flags, writing the boot loader, or sometimes even copying normal files into the correct spot (read: sector) in the partition and set the files' attributes/permissions. Unless you're lucky to have those things available, due to a previous boot disk creation, a formatting tool that writes the boot loader to the MBR, etc., you'll need to do more steps to make the disk bootable
Specifically when booting in BIOS mode, the BIOS looks for the first sector (MBR) to see if there's a valid boot signature 0xAA55. If yes then it loads that sector and transfer control to the boot loader in the MBR. The MBR describes the partition configuration, therefore it cannot lie inside the partition and is not what you can copy with normal tools.
Besides, since the MBR is too small to be useful, most modern boot loaders split the boot process into multiple stages, with the boot code in the MBR loads its next stage. The further intra-stages are again often put in regions outside the partitions. Some may put it in the EBR, but grub usually put its second stage in the empty area between the first partition and the MBR called the post-MBR gap. That's why if one doesn't align the partitions properly, there's no space for grub to put its boot code, resulting in embedding error
Many boot loaders like LILO or old Windows/DOS boot loaders also hard code information in the MBR, like the position of the next stage or of the system files. They don't work by reading the partition data but read some hard coded sector instead, since it'll take too much code to parse the file system which is very hard to be squeezed into tiny spaces like the MBR or post-MBR gap. Even grub supports such hard coding. That means some system files have to be at the exact location, sector-by-sector, which you can't also achieve with a normal copy. That's the reason you see "non-movable system files" while running Windows defragmenter or shrinking file systems, which is sometimes not actually correct, because it's just that Windows is too afraid to move those files even though modern boot loaders are a lot smarter and don't care about such things.
And after all, you also need to set the boot partition as active to let the boot loader know what to boot. That has to be done by a partitioning tool or by hex editing manually, since it's also put outside the partition area.
In UEFI things are a lot easier. It knows about FAT file systems (and even more file systems on non-standard implementations), therefore boot files are stored in the EFI system partition, A.K.A ESP. The UEFI loads the *.efi applications in the ESP which will then load the operating systems.
UEFI firmware supports booting from removable storage devices such as USB flash drives. For that purpose, a removable device needs to be formatted with a FAT12, FAT16 or FAT32 file system, while a boot loader needs to be stored according to the standard ESP file hierarchy, or by providing a complete path of a boot loader to the system's boot manager.
So basically you just need to copy the *.efi file(s) to the ESP and put system files in the correct folder. However, there's still a small problem because the FAT partition containing the *.efi file must be marked as ESP in the MBR or GPT table outside the partitions, which can't be done by copying like above. In particular the partition type must be changed from 0Ch/0Bh/whatever to EFh in MBR and to C12A7328-F81F-11D2-BA4B-00A0C93EC93B in GPT, since the ESP is not actually FAT12/16/32 but an independent file system based on the FAT file system family
And there are still many other partitioning schemes like BSD disk label or APM which need to be modified differently to boot. Or the USB sticks might have been formatted without a partition table at all (AFAIK Windows does this by default), therefore making it bootable will be different. But the same limit applies: you need to modify non-partitioned areas
2What do you mean by "copy/paste"? Obviously, you have to copy the parts that actually make it a bootable drive (such as the bootloader, etc.) but there is no reason this should not work. – Jörg W Mittag – 2018-09-06T07:51:52.007