**Note:** I'm looking at this question after this edit was made, and taking it into account:

> **Note:** I specifically mean the multi-round password hashes described by the linked documents and marked with the codes $5$ and $6$ in crypt hashes, not a single round of the plain SHA256 or SHA512 hash functions.

---
Looking at the long, 22-step algorithm in [this link you provided](https://www.akkadia.org/drepper/SHA-crypt.txt), I'd rather flip a question around: why would you prefer to use this instead of [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) with HMAC-SHA2?  Because, at least as presented:

* [The definition of PBKDF2 looks much simpler.](https://tools.ietf.org/html/rfc2898#section-5.2)  This is because it is more modular—it defers most of its work to an externally-supplied pseudo-random function. This is normally instantiated with [HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code), which in turn defers most of its work to an external hash function like SHA-1 or SHA-2.
* This means that the security of PBKDF2 should be easier to analyze.

In contrast, the algorithm in the document you provide lists a ton of steps whose motivation is harder to understand.  For example:

    11. For each bit of the binary representation of the length of the
        password string up to and including the highest 1-digit, starting
        from to lowest bit position (numeric value 1):

        a) for a 1-digit add digest B to digest A
    
        b) for a 0-digit add the password string
    
        NB: this step differs significantly from the MD5 algorithm.  It
        adds more randomness.

It adds more randomness?  How does it do this?  Why does it this step exist at all—is SHA-2 not adding sufficient randomness?  If SHA-2 isn't random enough, why use it in the first place?  And doesn't this step introduce [*secret-dependent branching*](https://cryptocoding.net/index.php/Coding_rules#Avoid_branchings_controlled_by_secret_data) into the algorithm, raising the question of possible [timing attacks](https://en.wikipedia.org/wiki/Timing_attack) against it?

I'm not by any means saying that the algorithms you link are insecure.  It's just that:

* The work factor they introduce comes down to the same thing that PBDKF2--HMAC-SHA2 would do (a large number of SHA2 iterations);
* They look very broadly similar to what you'd have if you unrolled a PBKDF2-HMAC-SHA2 implementation, but with additional complexity whose purpose I don't understand;
* So *at least as presented in those documents*, I find it harder to gain confidence on their design than I do for PBKDF2.  

---
**EDIT:** After I wrote all this I went and did a bit of research into this algorithm to try and understand it better.  First, from the question's own ["description"](https://www.akkadia.org/drepper/sha-crypt.html) and ["specification"](https://www.akkadia.org/drepper/SHA-crypt.txt) links, we learn that the algorithm was derived from an older MD5-based one by making relatively minor modifications.

This older MD5-based algorithm appears [the one that Poul-Henning Kamp wrote for FreeBSD-2.0 in 1994](http://phk.freebsd.dk/sagas/md5crypt), which [he no longer considers safe](http://phk.freebsd.dk/sagas/md5crypt_eol).  In the first link (where he tells the history of the function), he mentions that glibc adopted his function as well.  He also links to [Provos and Mazières' 1999 paper on bcrypt](http://static.usenix.org/event/usenix99/provos/provos_html/index.html) and mentions that it expressed some disapproval, and funnily enough [they highlighted the same step that caught my attention above](http://static.usenix.org/event/usenix99/provos/provos_html/node10.html#SECTION00061200000000000000):

> MD5 *crypt* hashes the password and salt in a number of different combinations to slow down the evaluation speed. Some steps in the algorithm make it doubtful that the scheme was designed from a cryptographic point of view—for instance, the binary representation of the password length at some point determines which data is hashed, for every zero bit the first byte of the password and for every set bit the first byte of a previous hash computation.

But I think this explains the motivation of the newer functions that you ask about: they are a very minimal modification of an older function that predates most of the modern password hash functions, whose design has been called into question but is likely not fundamentally broken, just pointlessly complex.