Why would a directory have the sticky bit set without the executable bit?

From the manual page for sticky:

STICKY DIRECTORIES

A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.

Any user may create a sticky directory. See chmod(1) for details about modifying file modes.

The upshot of this is that only the owner of a file in a sticky directory can remove the file. In the case of the cron tables, this means that I can't go in there and remove your cron table and replace it with one of my choosing, even though I may have write access to the directory. It is for this reason that /tmp is also sticky.

What purpose does setting a sticky bit on a directory without the executable bit serve?

drwx-wx--T 2 root crontab 4096 Apr 24 15:00 /var/spool/cron/crontabs/

What you're looking at is similar on Debian. The directory does have the executable bit set, for the owner and the group. Just for the owner, sticky doesn't make much sense, since that's by definition only one user (and the owner gets to override sticky anyway). But for the group, it matters exactly as much as for world-writable directories like /tmp, namely that regular users can't remove files belonging to other users.

But why would anyone be a member of the group crontab?

To be able to modify their crontabs, of course! Debian's crontab works with setgid privilege, thus allowing any regular user to access that directory, with their own UID, and with the GID of crontab. That's slightly safer than letting them run crontab with setuid privilege since keeps the users separated from each other.

-rwxr-sr-x 1 root crontab 36008 Jun 11  2015 /usr/bin/crontab

Now, normally, the files in the directory are owned and named by their respective owners, and if crontab only allows to remove the user's own crontab, there shouldn't be a problem. Having the file permissions set up like that works to protect from bugs in the program, and makes the actual UID of the accessing user relevant, not just their name.