The pipe and redirection are different animals, so to speak. When you use here-doc redirection ( << ) or redirecting stdin < the text doesn't come in out of thin air - it actually goes into a file descriptor ( or temporary file, if you will ), and that is where the binary's stdin will be pointing.
Specifically, here's an excerpt from bash's source code, redir.c file (version 4.3):
/* Create a temporary file holding the text of the here document pointed to by REDIRECTEE, and return a file descriptor open for reading to the temp file. Return -1 on any error, and make sure errno is set appropriately. */ static int here_document_to_fd (redirectee, ri) So since redirection can basically be treated as files, the binaries can navigate them , or seek() through the file easily, jumping to any byte of the file.
Pipes , since they are buffers of 64 KiB (at least on Linux) with writes of 4096 bytes or less guaranteed to be atomic, aren't seekable, i.e. you cannot freely navigate them - only read sequentially. I once implemented tail command in python. 29 million lines of text can be seeked in microseconds if redirected, but if cat'ed via pipe , well, there's nothing that can be done - so it all has to be read sequentially.
Another possibility is that the binary might want to open a file specifically, and doesn't want to receive input from a pipe. It's usually done via stat() system call, and checking if the input comes from a S_ISFIFO type of file (which signifies a pipe/named pipe).
Your specific binary, since we don't know what it is, probably attempts seeking, but cannot seek pipes. It is recommended you consult its documentation to find out what exactly error code 14 means.
NOTE: Some shells, such as dash ( Debian Almquist Shell, default /bin/sh on Ubuntu ) implement here-doc redirection with pipes internally, thus may not be seekable. The point remains the same - pipes are sequential and cannot be navigated easily, and attempts to do so will result into errors.