After some further investigation, I think what's going on is this:
the "sticky bit" based locking applies to maildrop, however, it does not seem to apply to mail delivered by the courierlocal transport module. The courier online documentation: http://www.courier-mta.org/local.html
Output module setuids to the user indicated in the host parameter. If $HOME has the sticky bit set, defers the mail. attempts to open and read delivery instructions from .courier file specified by the address parameter. If can't open the file, or if it's empty, message is delivered to the default mailbox. Delivery instructions are read, a line at a time. Lines ending with \ are concatenated with the next one. A delivery instruction may specify a mailbox, a forwarding address !user@host, or a program delivery | The output module appends a Delivered-To: userid-ext@defaulthost header. If the header already exists, the message is bounced as a mailing loop.
suggests that (like in qmail) setting the sticky bit on $HOME *should* defer mail, but in practice, this doesn't happen. The courier-mta docs aren't very clear as to how mail is supposed to be delivered by default (in particular whether or whether not courier invokes maildrop by default, and/or how to force courier to invoke maildrop for all local deliveries, if one can do such a thing) is not clear. I believe this is true in the Ubuntu Xenial courier packages as well as the debian packages. More relevantly, it's also true when I build using the build scripts from the Arch Linux AUR, which I can easily see do not patch the courier source in any way (they are also still based off of 0.75.0, not the most current release). So I would say this is not a debian-specific bug, or even neccessarily a programming bug in courier, but rather a matter of unclear documentation upstream.
