Prima o poi su questa cosa ci scriverò un articolo. Il problema non è tanto la presenza, quanto il fatto che la maggior parte dei linguaggi, C# compreso, non obbligano il programmatore a gestirle. Ricordo che ad esempio in Delphi bisognava andarsi a vedere quali eccezioni generava un metodo di una classe, perché comunque il compilatore non ti obbligava (non lo fa neppure ora) a gestirle. Di fatto si finiva per non gestirne molte, lasciando il compito all'oggetto TApplication. Dunque veniva meno lo scopo per il quale le stesse sono state introdotte. Java invece ti obbliga a gestirle ed anche se l'onere è superiore, il risultato è che se non la gestisci è colpa tua e non del compilatore, che nell'obbligarti a prenderla in considerazione ha fatto il suo dovere. Da questo punto di vista (e non solo da questo) C# lascia molto a desiderare.
L'altro problema è che i sistemi operativi usano delle librerie di funzioni, le classiche DLL nel caso di Windows, che sono librerie di funzioni e non di oggetti, pertanto i vari ambienti di sviluppo spesso non fanno altro che incapsularle in classi e ritornare delle eccezioni, che magari non sono neppure in grado di gestire tutti i valori di ritorno delle funzioni che incorporano. Ed anche questo lo trovo paradossale.

Credo che il termine "eccezione" non vada inteso come qualcosa di eccezionale che è difficile che accada... più che altro lo intenderei come un evento inaspettao che renderebbe non valido il nostro set di istruzioni.
In linguaggi come Java le eccezioni devono essere tutte gestite... nel mio caso personale con un UML d'avanti agli occhi (o un diagramma delle classi in testa) gestisco le eccezioni direttamente nel metodo, oppure le "throwo" al piano superiore in base alla logica dell'applicazione... con un poco di esperienza (e voglia di cambiare svariati metodi di codice) troverai il metodo più corretto per capire come gestirle...