I think the goal is to have patches based on the latest version possible, but not to make this a barrier to people working on patches. Here are some more expanded comments, based on my limited experience:
Personally, I would develop patches based on stable releases of Sage. Sometimes alphas or release candidates have some test failures that are known to the release manager and will have to be resolved before the final release; these could be potentially confusing as a developer if your patch is working on a related component, since it may be difficult to tell which failures are caused by known issues, and which are caused by bugs in your patch. But there may be good reasons in some circumstances to base your patch on a pre-release version (e.g. it fixes something relevant to your patch). In the end, I think this is up to the developer.
As for developing with older stable releases, patches have to apply to the latest stable release in order to be finally included in a new release. Sometimes patches simply apply without problems to later releases, and then nothing has to be done. But if they don't, these problems definitely have to be fixed. I think most patch authors would be happy to have you rebase their patches -- I certainly would!
However, for the purposes of actually solving the programming or mathematical problems relevant to the patch, one doesn't have to necessarily work with the latest release of Sage. Since rebasing is usually a straightforward task, the real value in a developer's work is in writing the initial patch. Get something that works correctly in some version of Sage, and then make sure it works with the latest stable release. Of course the greater the gap between the version you develop with and the latest version, the more difficult the rebasing will be, but working two or three point releases behind the latest probably isn't a big deal.
Update: As @kcrisman points out, having a patch apply successfully to the latest stable release is necessary---but not sufficient---for the patch to be included in Sage. The patch must also apply to the latest pre-release, and not conflict with other patches to be merged in the next (pre-)release. He is right (of course!) to point out that testing against the latest pre-release is the best way to be sure your patch is ready to be merged.
However, motivation to test on the latest pre-release should be tempered by the understanding that the review process will probably take longer than expected (several pre-releases, and maybe several stable releases), and (as far as I know) binaries for pre-release versions are only available for the machines at the University of Washington. A person without access to these would have to build each pre-release from source just to test the patch. This can be tedious and time consuming, depending on one's resources, so I wouldn't necessarily recommend it for everyone.
