The following commands seem to be roughly equivalent:
read varname varname=$(head -1) varname=$(sed 1q) One difference is that read is a shell builtin while head and sed aren't.
Besides that, is there any difference in behavior between the three?
My motivation is to better understand the nuances of the shell and key utilities like head,sed. For example, if using head is an easy replacement for read, then why does read exist as a builtin?
Neither efficiency nor builtinness is the biggest difference. All of them will return different output for certain input.
head -n1 will provide a trailing newline only if the input has one.
sed 1q will always provide a trailing newline, but otherwise preserve the input.
read will never provide a trailing newline, and will interpret backslash sequences.
Additionally, read has additional options, such as splitting, timeouts, and input history, some of which are standard and others vary between shells.
read can parse parameters separated by the internal field separator $IFS. @ramesh's strace trick is also an awesome way to analyze differences. For one thing, you can parse text with read, not just take a whole line
echo "foo:bar:baz" | { IFS=: read one two three echo $two } 
read, exactly, you parse it with $IFS. IFS=:; set -- ${0+foo:bar:baz}; echo "$2" accomplishes the same - and it requires no |pipes or cloned subshells. Or: IFS=:; printf %.0s%s%.0s\\n ${0+foo:bar:baz}. Else: echo foo:bar:baz | { IFS=:; set -- $(cat); echo "$2"; } if you must have the pipe. In any case, the splitting is a result of your setting $IFS; not necessarily that you read it. read assigns the split parts to variables. Builtins are present as a way to have the system calls more faster. So, I believe read command is present as a builtin to be more efficient.
Quoting from here,
These builtin commands are part of the shell, and are implemented as part of the shell's source code. The shell recognizes that the command that it was asked to execute was one of its builtins, and it performs that action on its own, without calling out to a separate executable. Different shells have different builtins, though there will be a whole lot of overlap in the basic set.
Now, I would like this to be experimented by yourself, so that you can understand why read is present as a shell builtin.
Normally, you couldn't do strace on shell builtins. However, there is a workaround for this as well. This is explained pretty neatly in this answer.
stty -echo.cat | strace bash > /dev/null.strace as it is pretty big.
read builtin in /bin/sh pre-exists head and probably sed. read is a builtin and skips the overhead and bookkeeping involved with starting a new process. You can use read varname only inside a shell script but other two you can use without writing shell script.
For example:
You can use varname=$(head -1) and varname=$(sed 1q) simply as a command in the terminal, but you have to provide your argument as well i.e. which files topmost line you are referring i.e. varnam=$(head -1 file1).
read varname outside a shell script. Try it! There are very few things you can do in a script that you can't do at a prompt in the "sh" family of shells (whether they are very useful is a different matter).