It's not ludicrous, it was a very deliberate design decision.

First, you only get emails if the program produced output. The Unix Way states that programs should not produce any output at all when the command was successful and everything went fine. (Unless of course the intended job of that program is to display output.)

Also, you have to keep in mind that Unix was designed to be a multi-user operating system. Meaning one machine to hundreds or thousands of users. When you submit a job with `at` or `cron`, it _only_ makes sense that you want to see the output of that job somehow, and email was the easiest and best way at the time.

Imagine the headaches of trying to admin a Unix system with thousands of users, all of who can create a cron job to run every minute or hour and forget about it because they _never, ever saw the output_?

Cron emails you by default, and I think that is the correct choice. It _should_ be up to the user to figure _which_ output they do not want and tune their jobs (or programs) to match. It's not even hard, you just redirect stdout to /dev/null.

Yeah, I hadn't considered the utility of this in a situation with many people submitting jobs to run on mainframes. To me, the logical default would be to output to logfiles rather than depend on an email server being available, but in the historical context I suppose it makes sense.

About 20 years ago when I set up my first server and wrote my first cron tasks on it, I didn't know that cron sent output to email. The root email address on that server was set up with a mailbox on the server itself, that was unused and never checked. After a year or more, I started mysteriously running out of disk space and was baffled until I found 10+ Gb of unread emails in that account.