Enabling the statement cache should work well in most cases. I cannot quote exact figures for improvements, but we have it enabled on some of our servers where it seems to be working quite well. These fire off a lot of small repetitive ad-hoc queries against the server, and obviously a lot of time and CPU is saved by ASE not having to regenerate a new query plan for each of them.
On one development server we clocked over 2.6 billion I/O operations against two tables in 2 separate databases in just under 12 Hours due to a buggy application where it fired the same query at the server looking for "events" in a table. The same query was repeatedly being executed at a rate of about 10-20 times a second each from each of 2 the application servers.
We did have an issue a few months ago on another server where it actually broke some functionality of another application when we enabled it. This occurred mainly when executing some stored procedures which accepted quite a large number of parameters for facilitating updates. I cannot remember exact specifics such as error messages and the likes, but we suspect it was due to buggy ASE behaviour when the complete statement (exec sp_xxx @param1='value',...) exceeded roughly 16K (if memory serves me correctly). Disabling the statement cache resolved the problem right away.
Your best bet would be to test it in a development environment first and check that no "funnies" occur.