When an existing filesystem is imaged, it usually means creating a block-by-block exact copy of the contents of the block device underlying the existing filesystem. It is literally an exact copy of that storage as it was at the time of imaging.
An ISO image is a bit different. It is a file that is constructed out of a set of directories and files defined by any means, in order to be a block-by-block exact copy of what a CD/DVD/Blu-Ray produced from that data will be. It includes the ISO9660 filesystem metadata, created at ISO image creation time.
The ISO image format exists because CD writer devices could initially only write to the disc in a sequential-access fashion, and could not stop in the middle of a write operation without ruining the disc. So you could not write a file here and another there, making it up as you went: you had to have all the files and all the metadata that would make up your CD-ROM (or audio CD) specified in advance, down to the last byte, before firing up the writing laser, and then write the entire disc, or at least a complete data or audio track, in one go. This was fine for the mass production of pressed audio CDs and CD-ROMs.
(Then, CD-Rs were introduced and it was found inconvenient to have to waste an entire disc even if you did not have a full 650 MiB to write... so multi-session CD writing was developed. Later, a more seamless write start/stop technology made it possible to develop packet writing for CD-RWs, and the UDF filesystem was developed to be optimized for that... but I digress.)
You cannot create an image file out of a directory quite the same way you can from an entire filesystem. A filesystem image includes the filesystem metadata that describes which blocks are allocated and which are free, and the physical locations of each block of each file and directory on the block device containing the filesystem. That information only makes sense in the context of the rest of the filesystem.
Trying to copy that information without also copying the rest of the filesystem would be mostly useless: when restoring files from such an image to a new filesystem, you would have to disregard the original block location information and let the filesystem driver place the files and directories according to which blocks on the destination filesystem are free. Otherwise you might overwrite and corrupt existing files and/or directories when restoring your "image".
So, when "imaging" directories rather than complete filesystems, it makes sense to only store the (relative) pathnames, file and directory ownerships, permissions and other attributes, and the data within the files. And when you develop a file format optimized for this, you'll get an archive file: for example, a
.tar file. Add compression to the concept, and you have a
.tar.gz or a
.zip file, or any of the numerous compressed archive file formats.
A loop device is not necessary in creation of image files: to create an image of a filesystem, you just read all the blocks of the block device containing that filesystem in order from the beginning to the end, and write them all into a single file, while ensuring that the filesystem that is being imaged is not modified during the imaging process.
A loop device allows accessing the contents of an image file without writing it to a "real" block device.