Creating a named cache will not help this - this is spinning on the spinlock for the object DES structure - which has pointers to indexes in memory, etc - but it does NOT contain catalog information. However, it does contain MDA counters. Check to see if Object Lockwait Timing is enabled - if it is, depending on the version of ASE, this triggered high spinlock contention on object manager. However, there also is a keepcnt on DES that is a source of contention that is resolved in ASE 16 with the atomic operations vs. using a mutex.
It is *always* beneficial to have a separate named cache for application database system tables - as noted, DES structures (including IDES, PDES) are more for locating stuff in memory vs. parsing/compiling queries - and especially when loading stats for optimization.
One aspect of note is that a DES is used for any object - temp table, real table, stored proc, default, rule - essentially, if it exists in sysobjects, it may need a DES. You might find that the DES contention is more due to either a) a very commonly invoked stored proc; b) a ton of temp tables, c) triggers that are invoked a lot - doing a des bind on them may help without causing issues with reorgs.
I would suggest reading the section on Object Manager Tuning in the old ASE whitepaper "Managing Workloads with ASE 15 ...."......although most of what it tries to point out is sort of already implied in your problem as rdesmgr_spin is the Object Manager spinlock vs. the Object spinlock (which is much more easily tuned).
