Yes, retargeting serial queues to a non-overcommit queue is a valid technique in some cases* for that reason. Ideally though you'd instead design your system to avoid hitting the lower non-overcommit thread count limit as well, because even 64 threads is probably more than you actually wanted. I'm personally fond of a minimalist "one queue (perhaps the main one) for fast operations, one queue for slow operations" approach, but I'm also more practiced in writing code that runs in system daemons, where any threads I create are competing with the foreground app.
*e.g. a system that creates an arbitrary number of objects, each of which have an internal serial queue, which they block loading data for the object from disk