Could the issue be something other than 'object lockwait timing' ? Sure, but without some actual performance metrics all I could do is *guess* at what the issue might be.
The newest sp_sysmon output shows a grand total of 200K IOs per second on the default data cache with spinlock contention of 7-9%. The cache hits (200K/second) are tiny relative to the number of engines, and while the 7-9% spinlock contention is a concern, I don't see this explaining all of the 100% cpu utilization. [Yes, there are some steps you could take to reduce the default data cache spinlock contention, but that's another discussion.]
Transactional activity is quite low (for this number of engines). Cache hit rates are miniscule compared to what should be possible with 64 engines. There is some spinlock contention on descriptors and the default data cache, but not enough (in my opinion) to justify the 100% cpu utilization. There's little/no query compilation going on. I'm not seeing any 'normal' reasons for high cpu utilization.
I just noticed that you have disk mirroring enabled. If you're not actively using disk mirroring I'd suggest turning this configuration option off, too. [This requires a dataserver reboot for the config change to take effect.] [There is a small bit of overhead for ASE to manage disk mirroring, even if it's not being used.]
I'd suggest you explicitly disable 'object lockwait timing' and see if the issue still occurs. If you still see high cpu utilization then I'd try collecting the other data (see my previous post) and/or open a case with Sybase tech support.