Whether the cost estimates are accurate is another problem :-)
ASE does over-estimate the impact of 'relative' fragmentation particularly when scans are in memory. As such it can over-estimate the cost of a scenario like yours. This is why skipping maintenance can lead to unexpected bad plan flips.
You would need to look at the actual costs using 'set statistics plancost on' to work out if there are other costing reasons why the estimates themselves are inaccurate, but the optimizer has no knowledge of whether there is any dependency between the search arguments across the two tables so there will be legitimate guesswork going on.
Forcing queries/using abstract plans is a good thing for a whole host of reasons and if required you can force different plans dependant on datasets by splitting code. The only caveat with forcing is don't use it as justification to not keep statistics up to date. There are areas within the execution plans (I'm thinking hashing operators mainly) that are built using estimates derived from statistics. If the statistics are inaccurate or poor then these operators can be inefficient and you can have situations where identical plans (well, the exposed part is identical) performing significantly differently dependant on the accuracy of statistics at compile time.