Since version xxx (cannot find the proper reference, right now) the cron daemon refuses to run crontab files that have execute permissions for the "other" part of the permission bits. This is due to a kernel bug discovered in the past, for which an external user could gain control by running a cron job which generated a core dump in /etc/cron.d directory. I leave the security concerns to real experts in this field, but I can confirm that the behaviour you've noticed is the default, despite it's poorly documented.
Edit: just found a brief reference here:
http://slackrw.wordpress.com/2006/08...d-permissions/. My explanation was slightly incorrect: according to this article the permission bits are set to avoid the creation of the core dump inside /etc/cron.d (not necessarily from a cron job executed from /etc/cron.d itself).