That's one possible meaning of "flush"; however it's common to use it to mean not just "push dirty stuff out" but also "all your data is stale so drop it on the floor and refetch from the level below if anybody asks for it later". On x86 the "CLFLUSH" instruction does both "write modified data out to the level below" and "forget about the possibly stale cached copy you have". ARM generally avoids the term "flush" altogether and talks about "Invalidate" and "Clean" operations (where "Clean and Invalidate" does roughly the same as the x86 "CLFLUSH").
I guess this sounds a bit like nitpicking, except that in my experience if you're down at the level where you need to really care about what the cache is doing you probably also need to be precise in discussion of exactly what (possibly architecture specific) operations you're doing to your cache.
Ok.
"This style of memory management is known as write-back whereby data in the cache is only written back to main-memory when the cache-line is evicted because a new line is taking its place."
That sounds like a flush to me. Modified data is written back (or flushed) to main memory.
"I think we can safely say that we never "flush" the CPU cache within our programs."
Maybe not explicitly, but a write-back is triggered by "certain operations," (see the first quotation above).
So it sounds like the real "fallacy" the article is discussing is the idea that a cache flush is something that a program explicitly does. That would indeed be a fallacy, but I have never heard anyone claim this.
On the upside, the article does give a lot of really nice details about the memory hierarchy of modern architectures (this stuff falls out of date quickly). I had no idea the Memory Order Buffers could hold 64 concurrent loads and 36 concurrent stores.