A few ideas/questions/issues come to mind ...
---------------
Have you insured you have stats on the 3 referenced columns from the TOPERAFR table?
Is there a reason why an index cannot be added to the TOPERAFR table?
---------------
Have you by any chance disabled the use of REFORMATTING?
At the session level try running 'set store_index 1' (enable REFORMATTING) before running your query. If this allows REFORMATTING to be used for your query then you'll need to find out how/when/why 'set store_index 0' ('disable REFORMATTING') was initially run (eg, as part of a login trigger?).
At the server level I'd suggest the DBA find out if the server is running with -T328 enabled ('disable use of REFORMATTING') by running 'show switch'. If T328 is in fact enabled then a) see if disabling the flag makes a difference for your query and b) find out why T328 was enabled in the first place.
If your dataserver is running with T328 enabled, and you choose to disable T328 (ie, stop using T328), make sure the DBA removes any references to T328 from the RUNSERVER file (ie, you don't want to re-enable T328 next time the dataserver is bounced).
NOTE: T328 is not documented so if you're *not* using it I'd recommend you not try enabling it unless a) recommended by Sybase tech support and/or b) you test the flag in a dev/test environment before using in production.
NOTE: I worked at a client last year that had inadvertently enabled T328. While I ended up disabling the use of T328 I don't recall if it was a dynamic setting (ie, didn't have to bounce the dataserver). Sooo, if the DBA is unable to disable T328 via the 'dbcc traceoff' or 'set switch' commands, then the DBA will need to bounce the dataserver (after removing T328 from the RUNSERVER file).
---------------
What happens if you rewrite the query like such:
==========================
SELECT * FROM TCURDIVS t1
WHERE not exists(SELECT 1 FROM TOPERAFR t2
WHERE t2.ALT_TS >= '20131021'
AND t2.SIT_CD = 'L'
AND t2.DIV_ENT_CD = t1.DIV_CD)
==========================
NOTE: You can wrap this query in a 'set noexec off/on' pair to generate a query plan without actually running the query. ("Duh, Mark!" ?)
While this won't explain the non-use of the REFORMATTING command, I'm wondering if a rewrite might give the optimizer a better chance of coming up with a (relatively) more efficient query plan ... ?
---------------
According to solved cases @ sybase.com there's an open CR (488583, related to case 11680505) that seems to be a good match for your query. The gist of the CR is that the optimizer costs the query based on an assumption that the sub-query will only be executed once. The CR suggests a change to the optimizer to allow costing based on a the potential of having to run the sub-query multiple times.
Someone with access to Sybase's CR database may be able to jump in here to see if CR 488583 is still open and if so perhaps give some idea as to when it may be addressed.
The potential workarounds for this CR 488583 ... create in index that can be used for the sub-query ... or use an abstract query plan (aka AQP).
And assuming CR 488583 is still open, you'll probably need to open a case with Sybase tech support to see if CR 488583 applies in your case.