Before we start answering the subquestions, let's bring up some background knowledge.
The sponge construct was first proposed by the Keccak team as a bridging element in a security proof for the older RadioGatún hash function. On their web page, they describe it as a generalization of both hash function (var->fix) and stream cipher (fix->var).
Since SHAKE-128/256 are directly based on sponge constructs, we'll just assume for now that the authors intended XOF as the generic term for their trademark product Sponge.
type input output
stream cipher fixed-length key variable-length key-stream
xof variable-length data variable-length data
hash function variable-length data fixed-length digest
So question 1 can be answered as follows: no, that would violate the definition of XOF.
And question 2: no. They're stream ciphers, two of which use the counter construct.
If you search "cryptographic seed-expander" on Bing in 2018-02, then the first few results unrelated to Crypto.SE refer to the NIST page for post-quantum cryptography. The story goes like this:
Back in the early days of preparing for the contest, NIST specified that submitters obtain randomness source for their keygen-signing-encrypt functions using libc rand(). This was correctly met with protest by notable participants on the official mailing list.
After discussion, it was decided there would be separate randomness calls for 1.) generating small amounts of keying material sufficient for a given security level, and for 2.) expanding keying material into a longer bitstring from which mathematical objects could be extracted.
The latter has since been called "seed expander" in official NIST documents, which roughly corresponds to DRBG.
So question 3 can be answered as follows: It does what a DRBG/PRNG does. The interface of a DRBG applies.
I'd like to answer question 4 as follows: It doesn't make sense to compare them, because their purposes are different. And this difference in purpose makes their programming interface different as well. For example, the typical interface for a XOF function is much simpler than that for a DRBG, and has many fewer parameters to tune than KDF.