Original all three have different meanings and are (in part) based on different implementations. But, as you already assume in your answer, people may have taken the name and used it with differend (usualy simpler) implementations
Is there a backstory to the
The term "Catalog(ue)" goes quite in line how IBM's terminology is based on analogies to a library. A tape was called a Volume - like a book - structured with a volume labels (VOL1..9) holding information about the tape and header label (HDR1..9) for each file. A HDR1 label is essentially a description of the file (*1). Disks or DASD, as they called it, were as well named volumes and followed that same scheme. Now all HDR1 records are moved into a series of blocks building the Volume Table Of Content (VTOC). Much like in a book. Continuing analoge the collection of all files (Data Sets in IBM lingo) is called a Catalog.
In practical ways it's used by operating systems with a seperate database for all files known to an installation, eventually across multiple disks and tapes, online and offline as well (*2).
This wasn't only used by IBM, but followed by many others. Some in fact based the whole data management around such a catalogue. A nice example here is RCA's TSOS, where the system volume set always contained such a system catalogue. Like most systems of the time the basic structure of files on tape or disk were organized with 100% IBM compatible style volume labels (plus some extensions).
Adding a volume to the system also meant importing all VTOC (Volume Table Of Content) entries from that volume to the system catalogue. The information stayed there, no matter if the volume was online (mounted in a disk or tape drive) or offline. To purge an entry it had to be explicite 'exported'.
Such a catalogue allowed not only to hold additional information about the file, as well as spreading files across multiple volumes (*3), but most important to hold a catalogue of all files of all volumes known to the system. As a result meta information could be accessed without mounting a specific volume. Most important here would be the volume name itself, as now a user program could simply request access to a file, without caring or even knowing on what volume it is stored. The system would simply open it if online, or inform the operator got which volume to bring online. Quite an important layer of abstraction for larger installations.
On TSOS the command
FSTAT (FileStatus) was used to enquire information about a file or groups of files.
IBM itself of course used a similar catalogue system on their early operating systems continuing until today's zOS with a VTOC on each volume listing all Data Sets (their lingo for files) and a master-catalog, holding all known volumes, files and user-catalogs (*4), on their system volume.
Similar the term "Directory" is taken from real world directories. Were a catalogue collects multiple information items in an entry to be searched and manipulated, a directory offers directions to find something. Like a phone directory, a cities street directory, a store directory in a mall, or a mercantile directory of suppliers. Directories are usual a one on one relations listing some primary information under a secondary key.
"List" in contrast to "Directory" or "Catalog" is not named about the storage structure accessed, but simply named from the user side view of listing all files within a given context.
P.S.: I really miss the power of a system wide catalogue.
*1 - Fun part: all these headers are essential 80 bytes in size ;)
*2 - To avoid confusion, this is not about some optional file data base - like handy for many systems all the way down to the C64 - but catalogues as integral part of the OS. Neither TSOS of the 1970s nor today's zOS will start up without a valid system catalogue residing on the startup drive.
*3 - Parts on each volume looked like simple files, consistent only as storage within the volume. Somewhat like archivers used to spread large files/archives over multiple floppies.
*4 - No, these are not subdirectories, but complete stand alone catalogues that are mapped into the system catalogue when attached. This is useful to import and export whole groups of volumes, for example if the storage complex of another system has to be mounted to take over its workload.