I've always felt it was a very bad practice not to do it.

In a lot of companies but one they avoided it for fear of receiving emails. On that only company that did it, we made sure that mailbox was clean by actually having a look when cron scripts were crapping out or when users failed sudo repeatedly and contacted the users. It was a much better housekeeping than log on a box and see there are hundreds of unread emails but dismissing it like most do.

I think it's a fear of _sending_ emails. You could accidentally trigger a cronjob that sends a bunch of emails and gets you put on spam filters. Error reporting for cron is, of course, important; but the builtin email reporting is best used for the local machine/network. A more flexible and robust solution calls out to an API that handles transactional emails/push notifications with debouncing, escalation policies, etc.

Well, it depends! Because what you need to see more often is errors. You don't want successful notifications "spam" more often than error notifications.