To complicate things, there could be legacy jobs or reports that robotically access the database on a schedule, but it's defunct and no end user or business process really depends on it or even looks at it. That's why it's a best practice to state the purpose or business justification for a job within it's description, and also have one or more operators setup for each job, even if there are no routine email notifications. In this case the operators are really business owners who are there in case someone needs an actual human contact to vouch for the purpose or continued need of a process when it comes under scrutiny for some reason.

I'm speaking from the perspective of someone who helps manage a database environment containing 100+ production servers and 1000+ jobs. The first logic branch on my mental flowchart for troubleshooting jobs is: "Who who created this thing?" and the 2nd branch is "Do we actually need it?". Only when those questions are answered can I justify spending any serious time trying to fix or optimize it. Nothing makes me happier than to give the ax to some old resource hog of a job that's wasting server resources in addition to wasting DBA time.