> But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days?

I help run a 500 node HPC cluster that leverages procmail. Do I count?

> User crontabs on my system at least (Ubuntu) are in /var/spool/cron/crontabs/[username], not in $HOME anyway.

The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or some such.

> People have had systems where relying on accessing the home directory of a logged out user has been undesirable or impossible for a very long time.

I have daily experiences indicating otherwise. I would hazard to guess that many other syadins in academia & research would agree. Even assuming $HOME is in /home breaks a bunch of stuff:

* https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2004Sna...

> I help run a 500 node HPC cluster that leverages procmail. Do I count?

You do, but you're a tiny minority, and as noted /etc/procmail-rcs/ provides an alternative to putting them in /home. If that doesn't work for you, all you need is to not configure encrypted home directions and nothing changes.

> The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or some such.

So don't configure encrypted home directories, then. Nobody is forcing you to enable it. Or you can provide an alternative location, and let your users protect their data better and still be able to use cron jobs. It does not take any flexibility away from you, but it adds capabilities for those who want them.

> I have daily experiences indicating otherwise. I would hazard to guess that many other syadins in academia & research would agree. Even assuming $HOME is in /home breaks a bunch of stuff:

Your experiences with systems that are fine with accessing $HOME does not mean that there aren't plenty of systems where it has been an issue, hence why plenty of software supports alternatives.

Your point of not assuming $HOME is in /home is irrelevant to this issue. The point is that software have had to deal with a subset of users with setups where a users home directory is not necessarily accessible when the user is not logged in for many years. As such most software has options to avoid relying on a users home directory being present already, which reduces this to a relatively simple choice of whether or not you consider the ability to encrypt home directories to be worth making those changes for.

Maybe my point wasn't stated clear enough: the crontab itself is in spool, obviously, but the scripts started from crontab entries reside in my home directory. And while a procmailrc can live in some spool too, the files to be delivered into are in my home directory too.

So then you have two choices: Move them elsewhere, and be able to encrypt the rest of $HOME, or don't encrypt $HOME. This gives you additional options for protecting your home directory if you want it. Noone is forcing you.