Use case for extendable-output functions (XOF) such as SHAKE128/SHAKE256 FIPS 202 defines 2 functions, SHAKE128 and SHAKE256, as extendable-output functions (XOFs) that can have variable output length. But in Appendix A.2 marks:


  it is possible to use an XOF as a hash function by
  selecting a fixed output length. However, XOFs have the potential for generating related
  outputs—a property that designers of security applications/protocols/systems may not expect of
  hash functions


Later it describes a theoretical use case (and explicitly discourage such uses):


  For example, a naïve (and non-approved) way
  for two parties to agree to derive a 112-bit Triple DES key from a message designated as keymaterial would be to compute SHAKE128(keymaterial, keylength), where keylength is 112.
  However, if an attacker is able to induce one of the parties to use a different value for keylength, say 168 bits, but the same value for keymaterial


So what is the use case for these functions? Is there any reasonable use case where these functions should be used instead of standard (fixed-size output functions) SHA-3 functions?
As of now I can think of four different applications for XOFs.
Note that some change the padding depending on the requested output size and so the outputs are truly unrelated, Skein does this.

Signature message hashing. Using an XOF you don't have to rely on ad-hoc constructions for hashing the message in signature schemes to the appropriate size. For example, implementing RSA-FDH is trivial with an XOF while it is not so easy with fixed size hashes. As another example the CFRG of the IRTF adopted SHAKE-256 as the internal hash function for the Ed448 signature standard (which needs an 912-bit hash internally).

Stream ciphers. This may be a artificial but you can in fact abuse your XOF as a stream cipher if you don't want to trust the well studied AES-CTR or Salsa constructions. This was indeed proposed in the Skein specification.

Key derivation. Assume for a second that you didn't know HKDF. You trivially replace HKDF with an XOF in most scenarios as you could simply save the state after processing the master secret and then pad it with the context for each key-derivation. Or if you only need one giant block of derived bits, you'd need to call HKDF or a fixed size hash many times but your XOF only once.

Easier instantiation of random oracles. Some security proofs rely on the so-called random oracle model to prove the security of a given scheme. Normally you'd use some artificial construction around a fixed-size hash function to get the desired output size, but with XOFs you can just plug them right in without having to fear any mistakes on your side potentially breaking the proofs (most people don't know / understand in many cases, me included).


TL;DR: Native XOFs aren't necessary and can be emulated using known &quot;ad-hoc&quot; constructions, but they are highly convenient in random oracle based schemes, in signature message hashing and for fast and easy key derivation.