BLAKE2X can be used to generate arbitrary keying material from a suitable, secure input. That is, it can be used securely as a key-derivation function up to 4 GiB of data.
However, the security of such a key derivation function is limited to the entropy of the input and the state size of your BLAKE2 instance. For example, if you have only 32 bits of entropy in your seed, then the security of the construction is only 32 bits. Similarly, BLAKE2Xb cannot provide more than 512 bits of security, and BLAKE2Xs cannot provide more than 256 bits of security, because these are the limitations of their internal state sizes.
Fortunately, though, this isn't a problem because 256 bits of security is expected to be secure for the indefinite future. As long as you choose a seed with an appropriate amount of entropy (e.g., your system CSPRNG or a secure Diffie-Hellman key exchange, whether EC or not), then you don't need to worry.
The practical reason we use a key-derivation function to generate larger outputs is that sometimes we need larger amounts of keying material. For example, TLS and SSH both need encryption keys, nonces, and possibly MAC keys for both directions, which should be uncorrelated and may add up to over 1024 bytes, but the security of the entire connection remains no more than probably 128 or 256 bits (due to the key exchange). Similarly, expanding the seed of a Curve448 key into its two private components requires a substantial amount of output, but not more than 224 bits of security.
Technically, the construction you mention at first doesn't suffer from the limitations of the internal state size like BLAKE2X does. However, as I mentioned, this is only a theoretical consideration because BLAKE2X provides a completely adequate state of security. HKDF, which uses a structurally similar approach (extract and expand), is used in TLS 1.3 and is considered to be robust and secure.
