I think, first its because
button().click();
is cleaner/simpler code to a user than ..
GuiTestObject button = new GuiTestObject( getMappedTestObject("thebutton"));//This currently resides in the helper file.
button.click();
Second, the button() method can be passed an "Anchor" and a "Flag" also which is again implemented in the Helper class.so again
button(anchorobject,flags).click();
is simpler than having, one more button object
GuiTestObject button1 = new GuiTestObject(getMappedTestObject("thebutton"),anchor,flags);
button1.click();
In case you mean having something like..
GuiTestObject button = button();//where button() still is in helper class
button.click();
button.dosomthingelse();
Then we would need to specify the actual type of object for the button then we have a different TestObject type for Text controls and selects and trees etc. With this existing approach the user can be completely unaware of existence of different types of TestObjects (GuiTestObject / TextGuiTestObject/SelectGuiSubitemTestObject) etc which is returned by the getter method of an object.
What we are dealing with in the script is a TestObject which resides in the playback process. TestObject is just a specification to find an actual object in the application and create a proxy for it (which resides in the application process) , and this proxy is what gets released once a particular action completes (click() for instance). However the TestObject is still valid , and as you have rightly said RFT would again find the object if you reuse the testobject. TestObject would be taken care of by the Garbage collector as and when required, user can further optimize that code I guess. Finally to answer your question I am not aware what would be the downside of using the testobject you have. I don't think it will help you in terms of performance also though. Try timing how much time it saves you if any by using an Object instead of the getter , try it on Java application which is statically enabled.