I think you're getting ahead of yourself in assuming this is anything related to abstract query plans, there's no reason (yet) to even think they're implicated.
Sybase compiles procedures (and all code objects) into query plans in procedure cache. This is just like data cache, in that it is a Most-Recently-Used to Least-Recently-Used chain. Old pages will eventually get aged out of cache if other things need to be loaded into it. So it totally might be that overnight other processing is aging the query plans out of procedure cache and the first execution of the day reloads it.
Summary: Just because it was in procedure cache once doesn't mean it will still be there right now.
Sybase procedure cache is not re-entrant. This means a single query plan cannot be shared between processes. If two processes run the same procedure, each will get their own query plan in cache. If there is only one currently in cache (and it is being used), a new one has to be compiled and loaded.
Summary: Just because it's in procedure cache right now doesn't mean you can use it.
Even if there is a spare (unused) query plan in procedure cache, you might not use it anyway. If the procedure was created with the "with recompile" option, it will be recompiled every time it is executed. Or it might have been executed with "with recompile" which will have the same effect. Or someone might have run "sp_recompile" on a table that the procedure uses (commonly after some form of "update statistics" command), which will have the same effect. Or even without any of those causes, there are other possible causes for requiring a recompile of a query plan, like exhausting metadata cache descriptors, which will mark all query plans for an object as invalid.
Summary: Really, even if the query plan is in procedure cache right now, and no-one else is using it, doesn't mean you can (definitely) use it.
Ok, so maybe that first execution of the day, for whatever reason, is causing a recompile of a query plan. Would that really make such a difference as to increase <10s to >3m? Yes, it totally could, if the SQL in the procedure is complicated. If there is a join between 20 tables I would expect optimisation to take even longer. You don't say what version of ASE you're using - in ASE 15+ there are server limits on how long something will spend in optimisation precisely to try to avoid this kind of issue. I am guessing you are running an earlier version, in which case optimisation takes as long as it takes and there are no ways of halting it early once begun.
Summary: 10 seconds blowing out to 180 seconds isn't necessarily that extreme, if there is a procedure recompile happening.
Now, the real problem here is that most of the ways we have to determine if any of the above might be happening generally require sa_role. If you don't currently have that privilege there isn't going to be much you can do to investigate this. I will say there are many things we'd want to look at before it was reasonable to begin suspect abstract query plans were a factor.
To answer your specific question, there are indeed some sp_configure parameters that could be relevant to some of these possible causes, but without sa_role you won't be able to run the diagnostics to check, and you won't be able to change them anyway.
Let me ask you a new question - does it matter to anyone if the first execution of this procedure in a day takes 3 minutes?
