"How does this functionality work?"
What you are describing is not really functionality, it's dysfunctionality caused by a misconception. It's not cron that sends the SIGPIPE, but it is because of the way you are using it.
By default cron emails the stdout and stderr of a process to the owner of the crontab using sendmail (see
man cron; if you don't have an MTA installed, the output is just discarded), unless they are redirected. To do this, it must wait for the process to complete. However, if you have backgrounded the process with
* * * * * /bin/someprogram &
It won't wait, and if the program now tries to write to stdout or stderr, it will get a SIGPIPE, because the pipe is broken (the read end was closed). [This might also happen to a non-background process on older crons if your MTA is missing and you have a lot of output]
So I am going to guess that you have something like this in your crontab:
* * * * * /bin/someprogram > log.file &
Meaning the stdout is redirected to a file, but the stderr pipe is still broken. This has led you to the erroneous conclusion that "cron executes whatever program is sent to it in such a fashion that anything written to STDERR causes ... SIGPIPE".
You can fix your crontab by either removing the backgrounding
& or redirecting stderr too:
* * * * * /bin/someprogram 1>&2&> log.file &
If you want. WRT duplicating this yourself, as qqx says, just close one end of a pipe and then write to it.