You are copying a file to a block device. Let us consider the two.
A file is usually stored in a file system. The file is broken up to equal size blocks and generally stored non contiguously. The file system contains a table that links the blocks together.
Block devices also contain equal sized blocks. When the block device is an actually a physical device, such as a USB flash drive, these blocks are stored contiguously. Since the blocks are contiguous, there is no need for a table containing links.
Now, there are virtual block devices that are not physical devices, but rather are actually files themselves. Stored somewhere in these files is all the information needed to represent a physical block device. Also, these files may contain additional information needed to describe the physical device. An iso file is this type of file.
Block devices generally contain a table which define contiguous blocks called partitions. Not all block devices have such tables. File systems are usually stored in these partitions. Again, not all files systems require a partition container and partitions do not contain file systems exclusively.
Initially, the 16GB USB flash drive contained a partition table. This table had an entry that allowed for a FAT formatted file system to reside contiguously on most (if not all) of the remaining blocks.
The command you entered completely overwrote this partition table and partially overwrote the file system. In other words, the iso file was copied sequentially to the flash drive starting a the first block of the drive.
The end result? Well, the disk utility (actually macOS) thinks there is at least one partition on the USB drive and that this partition should contain a Windows_FAT_32 file system. Of course, this is wrong, but this what was interpreted from results of your dd
command.
hdiutil imageinfo /path/to/gparted-live.x.y.z-w.iso
. The thumb drive's partition map and file systems is/are broken now.