I feel this is a big chicken-and-egg problem (and @smac seems to want to break that), but I believe @Achllle has a valid point: people who work with and on ROS have a rather biased view of things (perhaps privileged almost?).
Not just because they are invested and have an interest in seeing it succeed, but also because they are much, much better informed as to its current state, what is and what isn’t possible and supported, what the roadmap contains (and where things are relative to that roadmap) and, last but not least (and this has been discussed in Shape the Future of ROS 2 Documentation as well), don’t experience the large gap between being able to compile and run the examples/demos and knowing how to build ROS applications themselves.
An example of this is the nr of issues on ROS 2 repositories (and on ROS Answers) where the poster reports a build issue which in the end turns out to be caused by them trying to compile master (or whichever branch) on Dashing/Eloquent/some_other_version. If you’re aware of the development practices, it’s obviously clear you should not do this and should checkout the appropriate branch. But it is apparently not so obvious to many users. And this is just one example, there is a myriad of things which are not obvious, unless you are part of the scene.
Changing the default branches to the ROS 2 ones just like that is going to contribute to the perception of things being underdocumented, underdeveloped and being “a mess” (note I wrote the perception, although in some cases it’s unfortunately true).
When should the change be made? I don’t know actually. But I do agree with @gbiggs that we cannot force this on “all of ROS” (whatever that means).