Which Red Hat / CentOS updates should be applied and on what schedule?

I manage a number of different web sites for various clients, and this is generally what I do.

First, the top priority for security updates should be the web application itself. The vast majority of attacks will be targeting your web site and the code that runs it, and this needs to be kept secure. If you use off-the-shelf web applications, this is one place where I would even consider automatic updates, but in no case would I let a security update for something like WordPress or Drupal age more than 24 hours before testing it and most likely rolling it out.

If your web app is custom built, ensure that your developers are keeping on top of security issues, to whatever extent that you can do so. This is a scenario in which your organization should be doing DevOps to ensure that the web developers and IT are working well together and that issues are resolved timely.

After that, the next critical updates I consider are those that "go viral" and that you hear about on national news, such as Heartbleed, POODLE, etc., as well as updates to anything in the critical path, like nginx and PHP for Drupal and WordPress sites. I apply updates for these as soon as they're available. I also am on the mailing lists for the upstream packages (e.g. I am subscribed to openssl-announce) so that I get notification for really important things as soon as possible.

Next, I apply updates to every public facing server (web front ends, load balancers, etc.), and every supporting server (databases, etc.) once a month. This includes any leftover security and bug fix updates. In many organizations this is done quarterly across the board, but it's my opinion that public web sites, especially those doing e-commerce, should not be left to rot for that long. I almost always do this the weekend after Microsoft's patch Tuesday, which is almost always enough time to hear about bad Microsoft updates (though I mostly run Linux systems, it's easier to have one weekend to update everything).

Finally, I sit back, relax and wait to see what breaks. Despite your best efforts at testing updates, something will eventually go wrong. Watch your monitoring system. If something breaks that isn't being monitored, fix it and then start monitoring it. Be prepared to rollback (yum history undo is helpful).

For a very large part it depends.

The obvious is that Critical security updates are typically best installed As Soon As Possible, but only you know your infrastructure and platform. What is ASAP is specific to you. If you're running a web server, something recent like:

"CESA-2014:1919 Critical CentOS 7 firefox Security Update"

is not an issue for you. No need to rush. If you're running 500 CentOS workstations, that Erratum may indeed be crucial and you would push out such an update without any or only minimal testing.
Such a decision should come as the result of an impact/risk assessment, possibly with the help of your security officer.
On the other hand, for you the risk may be mitigated because all work-stations are forced to use a web-proxy that will already block such malicious content and 500 highly paid users of those workstation not being able to work properly come morning may be an unacceptable risk too. Then ASAP means after careful testing.

In contrast often bug fixes are unimportant and can wait, unless your environment is actively suffering from those bugs, then you may want to resolve that ASAP.

That was something that Red Hat's Satellite server or project Spacewalk made easier, for each registered system you can see which errata and updates are applicable, and also the reverse, for each Erratum you see how many systems are impacted. That much nicer than only a list of packages that have pending possible updates

Some organisations I've worked at had very simple applications that would allow servers to be patched automatically. "In Red Hat we trust".
Others had two internal releases where all Errata would be accumulated and only very specific, remote exploitable Critical updates would be pushed out outside of that schedule. And one or two that were deemed critical for our set-up as well. In non-production push the updates before the start of the business day, mandatory testing in the morning, in production no more than 24 hours after release of the update.