There are a lot of streams in the worker because historically, CGI directly connected a worker's standard output and error streams (file descriptors 1 and 2 on Unix) to the web server. FastCGI kept the notions, but established new, separate FastCGI output and error streams for FastCGI-aware applications to use. It also specified that the standard output/error streams should be discarded.
So by default, that's exactly what the FPM master does: it arranges for workers' standard streams to be discarded. That's actually fine with PHP because the error logs go through the SAPI layer, and that layer writes them to the FastCGI error stream when FastCGI is active.
By default, that stream goes through to the web server, where Apache logs it to whatever error log is in effect. (Typically, I've worked on sites that have per-virtualhost logs. Especially for error logs, it's a lot easier to find the relevant messages when it's known that Host X is down.)
PHP-FPM, however, also has the option of setting per-pool php.ini values in the pool configuration. If a value is provided there (e.g. /etc/php-fpm-5.5.d/www.conf) for the
error_logsetting, then that pool will log to the specified destination instead of the Web server's error log. In other words, the
php_value[error_log]set in the pool configuration overrides the default behavior of logging to the FastCGI error stream.
These options turn out to be entirely independent of the master FastCGI configuration setting named
catch_workers_output. This option, in the php-fpm configuration (e.g. /etc/php-fpm-5.5.conf) controls whether the standard streams are discarded as specified, or if they will appear as lines in the master process's error log. Unless the workers are dying unexpectedly, this probably doesn't contain anything interesting.