If somebody already has access to the ser_users.php file, he's basically already capable of doing anything in PivotX, rendering this entire point moot
Not entirely true. As a security professional, when doing a pen test and when I find a way to get read-only access to the files of a web app (eg. ser_users.php), or its database, or whatever (eg. by an arbitrary file inclusion vuln, or a limited SQL injection flaw that doesn't for some reason allow me to change hashes), then I focus my efforts on breaking hashes, which then
give me more access (eg. the full privileges to a certain account). Password stretching would prevent me, or significantly slow down my attempt at brute forcing hashes. A good example of this is the recent PHPBB hack (back in Feb 2009 IIRC) where an attacker got access to its list of 400 thousand MD5 hashes and basically broke many user passwords.
Also, many users tend to re-use passwords on other systems, other websites, etc. So being able to compromise their PivotX password hashes gives me access to these other systems sharing the same password.
Basically, by itself this vulnerability is not "major", but as always you should think of the whole picture, and the concept of "defense in-deth" suggests that you should implement password stretching.
Now as far as recommendations goes, I recommend not
re-inventing the wheel, but reusing an existing secure password hashing algorithm. For example PHP's builtin crypt() function implements some of the best hashing algos out there (see http://php.net/manual/en/function.crypt.php
* CRYPT_SHA512 (most secure)
* CRYPT_MD5 (less secure, but still very good and perfectly acceptable)
Update the user's password hash from the old format to the new format at the first login. I believe that's how Drupal handled the hash algo change: http://drupal.org/node/29706