I'm very late to this thread and many of my own thoughts have already been expressed.
However, I'm incredulous that any serious developer would treat it as a matter of pride that they do not use error handling in ACCDB or ACCDE files distributed to clients.
Of course, like any experienced developer, I test my code thoroughly before it is released. I deliberately look for problems so these can be solved before end users are involved. I do this both to ensure UX is as good as I can make it and to protect my own reputation as a developer.
However, I am well aware that no developer is perfect and things may slip through...in extreme cases with errors not being noticed for several years.
As already mentioned, not all possible modes of use can ever be tested...some end users have ways of doing things that can never reasonably be foreseen...and which may lead to very obscure errors.
I ask my clients to report all errors...no matter how trivial...but inevitably that doesn't always happen.
As a result, after over a decade of continuous use by several thousand users of my main schools app I set up detailed error logging with automated emails sent to me (with the clients' permission) as the primary developer listing full details of what/who/when/where/why/how etc.
In the first month, I was inundated with automated emails which allowed me to fix issues going back a long time but that had NEVER been brought to my attention, nor had shown up in any pre-release testing. The majority of those errors pre-dated my own involvement with the application...though not all. Within 3 months, the errors had all been fixed and the emails stopped...to my relief.
That particular app was supplied with a highly locked down ACCDB FE. If it had been an ACCDE, the app would simply have crashed when those errors occurred.
Moving on from unintended programming errors, there are errors that are built in to Access that need to be handled.
There are several examples of this type. For example:
1. A report with no data is loaded from a form. Using the Report_NoData event the report is closed automatically.
However that triggers error 2501 in the calling form .
2. Code is used to select a file or folder using file system object (FSO). If the user cancels, error 5 occurs
In both cases, that error needs to be handled. If not, an ACCDE FE will crash.
So - do enlighten me, how would those be managed without error handling?