Are XOFs and KDFs more usable than DRBGs? CSPRNGs have 2 design requirements:


output unpredictability, 
back-tracing resistance. 


In addition to which, NIST SP 800-90Ar1 added other features such as a) instance customization/personalization, b) operation administration (reseeding counter, etc.). 

Of the three functions listed on Wikipedia page for CSPRNG, key and salt generation can be accomplished with any KDF (even ones based on plain hash functions), and nonce can be accomplished with a simple counter. 

And with the introduction of dedicated-purpose XOFs in the SHA3 standard, the problem of producing arbitrary-length string from a finite-length one becomes solved along the way. 

Both XOFs and KDFs are much easier to implement and use practically, so what's the point of designing DRBGs in the "NIST-SP-800-90A" way?
I don't know what the rationale behind the designs in the NIST SP800-90 standards were—internal discussions may be obtainable by public records requests—but I can hypothesize a few reasons:


Backtracking resistance.  While SP800-90C does cover KDFs (like HKDF and SP800-108), and while sponges are available now, there's more work to be done in SP800-90A to attain backtracking resistance:


A mere KDF, e.g. HMAC with a counter, does not necessarily provide backtracking resistance on its own unless you iterate it (like HKDF-Expand could be construed to do, but only for each info parameter independently).  Although it's not too difficult to show that this is safe—the expected length to cycle in the iteration of a large uniform random function is only square root of large, and it can't be much different for a pseudorandom function—application developers aren't going to prove this themselves and auditors want guidance from a standard.
A mere sponge XOF, e.g. SHAKE128, does not provide backtracking resistance on its own: if the full state is ever compromised, then you can simply evaluate Keccak in reverse until you get all the old outputs.  There are various ways you could work around this, but there's no one obvious natural way.

Hysterical raisins.  NIST SP800-90A predated sponge constructions, so the tools at hand were:


pseudorandom permutations (block ciphers) like AES
variable-input fixed-output hash functions like SHA-256
fixed-input variable-output hash functions like Salsa20 or AES-CTR
public-key cryptography for making back doors


Although Salsa20 used the model of a random permutation $\pi$ in the form $x \mapsto \pi(x) + x$ to approximate a random function, which in turn was used in ‘CTR mode’ to approximate a one-time pad, the pervasive design principle of building everything out of a single permutation—like we see now with Keccak, in SHA-3 and KangarooTwelve and Kravatte and Strobe, and even with other permutations like Gimli in libhydrogen—had yet to reach prominence.
Cost of collision resistance.  There seems to be a much higher cost to collision resistance than to preimage resistance.  But DRBGs don't need collision resistance.  So, e.g., AES-CTR_DRBG can presumably be faster than HKDF-SHA256 or SHAKE128.  (Of course, you could use a much faster Keccak sponge like the 12-round KangarooTwelve or even the 6-round Kravatte but they're not among the SHA-3 functions.)
Avenue for Dual_EC_DRBG.  It seems implausible that NIST would choose to standardize DRBG interface and security requirements only to introduce a back door—it's so foundational for so much cryptography that standardization would be well within NIST's purview even without the back door.  But the prospect of attacking this foundation could have motivated NSA to push slightly harder for NIST to standardize it.


That said, you're unlikely to get the real answer unless (a) you file a FOIA request to get the internal design discussions, or (b) someone from NIST hangs out here.