Don't forget that gzip/brotli only affects the shipping time. This would be the process:
1. Server: check Accept-encoding header for gzip or brotili support
2. Server: compress either brotli or gzipped file, or fall back to a raw file
3. Server: send data to client
4. Client: receive (and decompress, if not raw)
5. Client: parse (big) resource
Also, compression through uglifying/minifying improves parse speed, which is really helpful on (old) mobile devices. Adding compression through gzip or brotli introduces additional overhead, because the uncompressing step will be in-memory and stalls the processing of the file.
No, you don't need to waste CPU cycles on compression for each connection. You can store the .css.gz on the filesystem along with the .css and have the webserver pick up the appropriate file based on Accept-encoding.
That way you can precompress with the slowest compression options.
Of course, there are multiple ways to optimize it (like storing stuff at a CDN), but I'm pretty sure 95% of the people do not precompress their assets.
If you have a build step (you probably do), in most cases it's as simple as running `npm install --save` for your minifier of choice and adding one line to your build script.
Even if the difference is minimal, it could mean the difference between, say, three TCP packets and four, which adds up for users on high-latency connections.