1) No. As said by others, the data do not need to be stored intermediately
on hard disk. The producer programs for ISO 9660 can emit a data stream to
"standard output" and the burner programs can take this data stream by their
"standard input". That's called a "pipe", a very fundamental Unix shell
gesture.
The classic example is some variation of:
mkisofs /some/directory | cdrecord -v dev=/dev/sr0 -
My own way to do the same is:
xorriso -outdev /dev/sr0 -blank as_needed -map /some/directory /
(The data transfer is done internally between libisofs and libburn.)
Not to forget the GUI burn programs: K3b, Xfburn, Brasero, ...
They coordinate ISO producer program and burn program without much
assistance by the user.
Edit: Attempt to react on Nis' comment:
If you want to store not more than the content of a single file, then you could simply burn that file to the medium. If you later open file /dev/sr0,
then it will bear your stored content (plus probably some trailing garbage).
If you want to store more than one file, or file names and other attributes,
then you need to wrap your files into some filesystem or archive format.
This format will later be readable by the appropriate filesystem driver
(e.g. Linux "iso9660") or archive unpacker (e.g. program "tar").
You are of course free to pick only a few files from your hard disk and
to give them different names in the resulting filesystem or archive.
(mkisofs has option -graft-points and "pathspecs" /ISO/PATH=/DISK/PATH
to control the renaming. Some archive programs may have similar capabilities
to change file names when they get copied into their archive.)
Most filesystems would have to be created in a random-access writable
device or in a filesystem image file on disk. That's because there is
no producer program which would create them as sequential data stream.
Such a sequential stream is a precondition for piping.
Archivers (e.g. "tar" or "zip") and ISO 9660 filesystem producers have the
capability to emit their result as sequential stream. So they are the ones
which can pipe their output into the input of a burn program.
(End of editing)
2) Now for the reason why so many proposals are around, which tell you to
first store the ISO image file and to then burn it to medium.
In the bad old times of the first CD burners there was the risk of
"buffer underrun". As soon as the drive wrote faster than the ISO producer
program could deliver data, the drive threw an error and left the CD-R
only partly written. The chance for success increased if the computer
first ran the ISO program, until all data was produced, and only then
started the burn program to read the ISO image from hard disk.
This time ended in the late 1990s by the invention of "burn free", which
enabled the drive to wait for more data and to resume burning the CD.
The problem of buffer underrun and burn abort did never hit DVD or BD media.