Well, I've worked for a couple (financial/banking) clients that had 1000's of procs (and standalone queries) and had allrows_mix set at the dataserver level.
One client, after months of testing and retesting and tweaking countless queries to work 'properly' (99% of them having to be forced to use allrows_oltp), and still only having made a dent in the stored proc inventory, I was asked to help with the tuning efforts. To get through the migration (to ASE 15.x) I suggested getting back to comparable12.5 level performance by switching to allrows_oltp. We completed the (re)testing of all procs in less time than had already been spent trying to force every query of every proc to run under allrows_mix. Then we manually tweaked the (relatively) few procs that could benefit from merge joins (though in most cases we opted for hash joins since it eliminated most of the worktable overhead of merge joins).
Another client insisted on using allrows_mix and manually having to tweak large quantities of of their queries (stored procs and standalone queries). Yeah, they jumped through the hoops of trying to make merge joins run faster, failed to make any noticeable improvement, and continued on with forcing allrows_mix. They gave responses similar to yours when I suggested using allrows_oltp as their default setting soooo, it took awhile to work through their query inventory.
The first client understood the benefit of the KISS principle, and saved time by switching to allrows_oltp, which in turn free'd up my time to work on the more interesting/challenging performance issues (eg, improving EOD processing so they wouldn't overrun their SLAs). The second client eventually got their inventory 'tuned' but it took a looong time to get to the finish line with allrows_mix (thankfully I work on an hourly basis).