While I think I can see what RMS is concerned about, I am not necessarily convinced the concern is significant enough to warrant implementation of additional user action that would be required in order to activate packages in future sessions. One of the great benefits of the ELPA system has been how much easier it has made it to add useful extensions and keep those extensions up-to-date without requiring the user to write any ELISP. While I personally don't find writing ELISP a challenge, many do - or at least shy away from it initially.
Bottom line is that when you install most ELPA packages, the package will often install basic autoloads. This means that should you do something or execute one of the autoload commands, the package will load and run in future sessions. So, in effect, the answer to the original question is yes, packages are available and will be automatically loaded in future sessions if the user executes one of those autloaded functions. However, I'm not aware of any packages which setup hooks or add themselves to hooks so that the package is loaded without specific user action in future sessions (I have not tried all packages and it would certainly be possible for a package to do this, though it might be tricky to implement unless you edit the user's init file, which I don't think is normal for an elpa package).
I feel the basic mechanism to prevent packages from being available in future sessions is to simply remove them. I actually think this is a good practice as it prevents people from building up large numbers of unused/unnecessary packages that only slow down updates. It also reduces the likelihood of unused packages conflicting with used packages and works towards a cleaner environment. Given that re-installing is also trivial, I don't think this is too much of a burden should there be a package you only need very rarely. Anyone who wants something more complex is of course free to implement such functionality themselves.
Tim