There is a huge difference between explicitly telling a third party they are not allowed to compress content, and affirming that this action prevents the content from being compressed in the first place. I think the biggest problem in understanding what I am saying is that there are some abstract layers and unfamiliar computer terminology involved. So, let me do what I usually do in this case: explain it with a physical world analogue.
You have an envelope with a card in it where you've written your bank account number. You want to give that envelope to your client so they can pay you, but since they're always busy with meetings you have to go through their secretary.
If the envelope is sealed the secretary has no idea what the contents of the envelope are. They know the client is expecting something from you, though. They do not open the envelope. They give it as-is to your client who opens it. The writing on the card is not modified in any way. Your client sees exactly what you sent them.
If the envelope is not sealed, the secretary can open it and inspect the content. They decide that the best thing for the client is to photocopy the card at 400% magnification, putting the photocopy in the envelope instead of your card. They give the client this envelope with the photocopy, but not the original card. Your client sees the enlarged photocopy, not what you sent him. It's a different form of the same content, one that is more appropriate for this client as determined by their secretary without asking you.
However, the fact that you can seal the envelope DOES NOT mean that you cannot make an enlarged photocopy of the card yourself and put that in the envelope instead of the original card.
If the envelope is sealed, just like above, the secretary takes the envelope and gives it to the client as-is. The client sees the enlarged photocopy. This is the same content as the card (which you have, not the client) but in a format you determined is best for the client.
If the envelope is not sealed, just like above, the secretary takes the envelope, and inspects the content. The content is deemed to be in the preferred form for the client, so the client is handed the envelope as is. The client sees the enlarged photocopy. This is the same content as the card (which you have, not the client) but in a format you determined is best for the client.
Therefore, saying that sealing the envelope prevents you from providing an enlarged copy of it is not true. It's common sense.
Likewise, it is common sense that if you do not have access to a photocopier (maybe you were running late and couldn't stop by a copy shop) you cannot do the enlargement yourself. If you've sealed the envelope before handing it over to the secretary you cannot possibly have any reasonable expectation that the secretary would enlarge the card; by sealing the envelope you have explicitly forbidden them from inspecting and modifying the content.
But we don't have office stationary and people, we have binary data and computers, I hear you say. Same difference, I say! Why? Let's see.
"You" are the web server.
The "client" is the web browser.
The "secretary" is CloudFlare.
The "card" is binary data.
The "photocopier" is a piece of software which does Brotli compression.
The "envelope" is an HTTP request.
The envelope's "seal" is the no-transform attribute in the Cache-Control header.
If you rewrite the above story using the computer terminology you now understand what is really going on.
The existence or absence of the no-transform attribute in the Cache-Control header (whether the envelope is sealed) does not control whether Brotli compression (photocopying) is possible or not. It only prevents the caching proxy (secretary) deciding without asking the web server (you) whether to compress the data (make a photocopy).
Nothing stops the web server (you) from applying Brotli compression to the content (replace the card with an enlarged photocopy) before handing the HTTP request (envelope) to the caching proxy (CloudFlare), but for the fact of whether you have mod_brotli enabled (access to a photocopier).
If you do not have mod_brotli enabled (access to a photocopier) you can deliver an HTTP request (envelope) without the no-transform attribute in the Cache-Control HTTP header (unsealed) to CloudFlare (secretary) and it will decide whether it's appropriate to compress it with Brotli (make a photocopy) before delivering it to the web browser (client) without asking the web server (you).
If, however, you do not have mod_brotli enabled (access to a photocopier) AND you deliver an HTTP request (envelope) with the no-transform attribute in the Cache-Control HTTP header (sealed) to CloudFlare (secretary) then it will have no choice but to deliver the uncompressed (non-photocopied) content (card) to the web browser (client) because you have explicitly forbidden it from compressing (photocopying) the content (card).
To make matters more complicated, there are two photocopiers in our computer world: mod_gzip (Gzip compression) and mod_brotli (Brotli compression). If that hurts your brain, think of it in the analogue world example as one photocopier which enlarges to 200%, and one which enlarges to 400%. Maybe you don't have access to the spanking new model that does 400% magnification (Brotli), but only the older model that does 200% magnification (Gzip). You can put the 200% magnified copy in the envelope. If the envelope is sealed the secretary can't do crap about it, your client gets the 200% magnified copy. If, however, you leave the envelope unsealed, the secretary can blow it up to 400% magnification of the original.
If I put it this way do you understand why you got Gzip compression but not Brotli?
Again.
Whether we seal the envelope or not does not have any impact on our ability to put the original, a 200% magnified, or a 400% magnified copy of the content in it. Only our access to a photocopier, and which photocopier, has an impact. The envelope seal only controls whether the secretary can open the envelope and decide for themselves whether to replace its contents with a photocopy without asking us.
Whether we use "Prevent content transformation" or not does not have any impact on our ability to put the original, a Gzip compressed, or a Brotli compressed content representation in our HTTP response. Only our access to a compression module for Apache, and whether that's mod_gzip or mod_brotli, does. "Prevent content transformation" only controls whether CloudFlare can replace the file contents with a compressed version without asking the web server.
That's a fine but CRUCIAL distinction. Disabling "Prevent content transformation" IS NOT a requirement for Brotli compression. Install and enable mod_brotli in Apache and you'll have Brotli compressed data. The ONLY reason you need to disable "Prevent content transformation" in your specific use case is because you do not have mod_brotli in Apache and you cannot have mod_brotli in Apache, therefore you have to let CloudFlare do the compression itself. Only in your SPECIFIC USE CASE do you need to disable "Prevent content transformation" to allow CloudFlare to transform (compress) your content.
You do not have access to the good photocopier. Therefore, you must leave the envelope unsealed so that the secretary can make a larger photocopy for your client. If you had access to a good photocopier you wouldn't need to leave that envelope unsealed.
Is that clear now?
