What does the above operation have to do with 'duplicate input file descriptor'?
read actually reads from file descriptor 0 (the stdin). The <&4 isn't part of read syntax at all – it does not tell read to read from fd#4; rather, it duplicates fd#4 to fd#0 so that read will have the file available at fd#0 i.e. stdin.
(0 is the default target for <, so <&4 is short for 0<&4, if that makes it any clearer.)
It is 'duplication' because the result is that both fd#0 and fd#4 now refer to the same thing. The descriptor #4 merely remains unused but doesn't disappear anywhere.
Why does bash need to do that to read the file content using the file descriptor 4?
Most programs expect their input to be provided through file descriptor #0, which is considered the "standard input" or stdin. Bash's read has the same expectation. The redirection <&4 or 0<&4 copies fd #4 to fd #0 for the duration of the read command.
Although in Bash, ksh and zsh read actually does have the option to read directly from another fd, using -u:
read -u 4 content
You can do that if you're specifically targeting one of the feature-rich shells and not /bin/sh in general. (Your script currently requests #!/bin/bash so -u will always be available.)
This is not standard and other shells might not necessarily have it in their own versions of read, so using the < redirection is a more "compatible" method if you're aiming towards general POSIX shell compatibility.
Also, I would be very grateful if anyone could recommend any good online resource that could explain the concept of fd well, as I really can't grasp it by just reading the GNU docs.
File descriptors are not a Bash concept; they're a far more general concept that all programs (and most programming languages) have on Linux or on Unix-like systems in general. So instead, try C docs or Python docs, e.g. what C open() returns, how a program reads from stdin or writes to stdout, and how dup() and dup2() work (x<&y effectively does a dup2(y, x) to clone the FD).
