Have there been instances where the Customization route was opted for , instead of Configuration/Supported Customization ?

That is difficult to answer. I think there are use cases that perfectly fit Appian and the other stretch the capabilities more or less. In my experience, the more you stretch it, tho more problems you will have and loose ease and speed of development and maintenance.

I agree with Stefan, when you add customizations you increase maintenance and risk.  In my experience, for example, these can make upgrades much more difficult.  We used to customize Appian 10+ years ago when the functionality was growing but not as robust as it is today.  We are still just finishing removing all of the customizations and transitioning them to OOTB functionality as Appian has grown to cover all of our needs with supported functions.

I recall spending 11 hours on a call with an Appian engineer one day (after working the issue myself for a week), debugging a customization we had for JavaScript database calls (back in the day when we could not query the DB from a form (before SAIL).  We ended up finding a special character hidden in the code from a copy/paste which worked fine on one version of Appian but did not cooperate in the newer version.  I never want to do that again.

I would implore to keep customizations as a last resort.