The bytes that you XOR with the message to get the ciphertext are called the key stream. It is secure to create a key stream using a CSPRNG yes, a cryptographically secure pseudo-random number generator and a static seed.
However, there are practical issues if you use your system's CSPRNG:
- it may decide to (re-)seed occasionally;
- the algorithm may change over time or between systems;
- the way random bytes are extracted may change (it may e.g. decide to align on words).
So you have to be sure that the CSPRNG operation is cast in stone before you'd use it to encrypt something. In the worst case random data is included to seed your cipher in which case the data is effectively lost. This has happened before when the "SHA1PRNG" of Sun was replaced first by another algorithm and then by OpenSSL random data on Android.
Theoretically speaking, a stream cipher - or block cipher in a stream mode - are both CSPRNG where there is one seed (the combination of key and IV/nonce), a specific algorithm and a prescribed way of retrieving a key stream. So generally the boring answer is to use AES-CTR to create the key stream, and to use AES-GCM - which uses AES-CTR internally - if you require message authentication as well. On systems without hardware acceleration a stream cipher such as ChaCha20 could be used instead.
Slightly less boring, you can also build a stream cipher out of a hash function by using counter mode. Preferably you'd use a MAC construction such as HMAC for that. Actually, most CSPRNG's that systems provide are not much more than that - but as stated, they are usually designed to provide random data, not deterministic data. And yes, generally these algorithms are slower than a dedicated stream cipher or hardware accelerated block cipher - they are more complex rather than less complex.