And simple accessors? Always include them, even if they don't do anything but return or access inst vars. A good SmallTalk compiler will always inline anyways, and thuse no need to worry about the extra message sends. You may need to change them in the future anyways. By including them from the start, you won't have to go through an object, and change every occurence of 'a :=' to 'self a:'. It's bitten me on the rear a few times.
I just did that in a fairly extensive piece of code recently. The exercise took less than fifteen minutes, and wasn't error-prone at all, thanks to the browser's facility for creating a browser for "defs of inst var." I simply went down the list, made the changes and had solid working code for the revisions in virtually no time at all. In comparison, it takes about that same amount of time to actually create all those accessors at the outset of the code, and is disruptive if I have to write new accessors on an "as you go" basis.
While I haven't been hacking Smalltalk seriously for more than a year or so now, this is only the first time I have had to do it. On a cost/benefit scale, I don't think this "bitten me on the rear" issue weighs terribly heavily.
On the other hand, I don't think any amount of evangelizing on the virtues of "always using accessors" will make a hog's breath of difference until the "optimization" and "automation" is actually accomplished by the compiler and the creation of accessors is automated. People simply won't choose a textually longer, more difficult approach that runs almost twice as slowly over a more textually straightforward process that requires no human overhead for creating all those accessors.
If using accessors is truly desired as a matter of course, I think someone need to take the assignment away from us expressly, perhaps dropping it into a primitive as has been suggested by some.