Thanks for the articles. So there is no way of knowing whether the object is cached or not. But what I can look for is consistency whether the same object is showing roughly the same count of read or write and then optimize.
That's about it, but I would think you realy mean the query showing the reads and writes, then optimise the query or create better indexes on the underlying objects. There's no real way that I know of, of telling if an object is cached from the Profiler results, but if you use STATISTICS IO you start getting an idea as logical IOs go up and physical IOs go down after cacheing. This is why you should do a DBCC DROPCLEANBUFFERS between tests to get consistent results.
In recent years I've tended to use Profiler as a tool to ID poorly performing queries, then pulled the code and run it in MS with STATISTICS IO and TIME ON, and looked at the actual execution plan. This, in conjunction with the DMVs in SQL 2005 gives a good combination of tools to improve performance.