That is correct. All objects in the document are immutable, so when an object is transformed or changed in some other way, the original object is moved into the undo stack and a brand new object (with copies of the attributes and userdata etc) is inserted into the document. Because of this, a reference to an object becomes stale once that object is modified, and as such you should not hang on to references for prolonged periods of time.
Storage and lookup of geometry and userdata is pretty optimized in Rhino. Are you sure that your original statement “I always have to store the id of the objects which is not very effective.” is quantifiable? Or do you just dislike having to take this approach in your code?
In the Rhino SDK we have to strike a balance between giving people the tools they need, but also making sure that no plugin developer can cause serious problems for everyone else by giving them access to sensitive instances. The solution we chose is to bottleneck all interaction with the Rhino document, so we always know when and how something changes.