You're on the right track when you say "They only change what is most important to differentiate themselves." From what I've seen, Python's getting used to write software management systems and installation systems more often than Perl (Gentoo's Portage and Fedora's Anaconda, respectively, come immediately to mind). Perl's still used to maintain and improve a whole bunch of older software management and installation systems. I think things are reaching a leveling-off point, though, where Python's encroachment is slowing down.
It's only natural that Python looks like it's "taking over" for a while, because in order for Python to get any traction it has to get some "market share" from somewhere -- and Perl pretty well dominated the niches where Python would be most effective for a long time. Now that Python has been expanding a little bit into some areas where there are more people who would like Python's way of doing things than Perl's, I suspect any further conversion will slow to the point where both Perl and Python will grow faster through expansion of both languages' capabilities into other "markets" than through any contesting over already claimed territory.
Ruby is just starting to get in on the action, from what I've seen, and when Ruby 2.0 hits it will probably accelerate slightly. It will probably take ground from both Perl and Python in the sysadmin arena, as it already has in a few cases (such as its growing use in ports management software for FreeBSD, for instance). Eventually that, too, will reach a state of equilibrium with Perl and Python. So it goes.
I've yet to see a distribution that doesn't offer perl.
It would be a strange Linux distro indeed that didn't offer Perl at least through its software management system. I seem to recall that FreeBSD removed Perl from the base system a while back, but I think that's just because the FreeBSD folks are interested in minimizing the number of interpreters that are part of the base system altogether. I don't recall Lisp, Lua, Python, Ruby, or Scheme interpreters being part of the base system either. This would be why, every time I write a Perl or Ruby script (and I've even written a couple of Python scripts lately -- le shudder), I find the interpreter in /usr/local/bin/$foo rather than in /usr/bin/$foo (though there is a symlink from the latter to the former, while there are not similar symlinks for Python and Ruby, by default).
Of course, officially the problem with including Perl in the base system was related to FreeBSD discussions on whether to differentiate between the interpreter and the Perl standard distribution libraries when determining what's in the base system. The ultimate official opinion seemed to be that including all the libraries in the Perl standard distribution along with the Perl interpreter itself would be too big a wad of stuff for the FreeBSD base system, so it has been relegated to ports instead. I still think FreeBSD may have a "fewest interpreters in the base system possible" bias, however.
Interesting note: In the midst of browsing through FreeBSD ports, double-checking to make sure I wasn't misspeaking, I stumbled across an interesting port called ruby-perl. The description:
This is a Ruby extension module to use the functions of Perl from Ruby +. You can also call Ruby functions back from within the Perl code. Author: Yoshida Masato <email@example.com> WWW: http://www.yoshidam.net/Ruby.html#perl
For someone that likes both Ruby and Perl so much, I sure do seem to be ignorant of some stuff that would be right up my alley. I had no idea this thing existed. Unfortunately, I seem to have discovered it in time for the message on its homepage "This library is not maintained now."
CopyWrite Chad Perrin