Yes, the 40x faster is only for the runs after the first in this scenario. That said, if I disable the incremental cache locally (dprint check --incremental=false) and run this on the example code linked to in the article, on my machine the first run is 8.0s. If I run prettier's CLI it's 24.8s. dprint is faster because it formats files in parallel with Prettier and has Prettier snapshotted in a Deno runtime. There's some thread contention that's making it a little slower than it could be with v8 and I've been lazy to investigate it.
Also, dprint uses very fast globbing with two threads working together in order to collect files. I would guess Prettier would still be slower if it did this because it's programmed in JS (though not by much), but it doesn't do it.
Adding caching to Prettier is reasonably easy, and most people will already have it through lint-staged or something similar.
I'm much more impressed by "dprint is 3* faster than Prettier for the same task" than "dprint is 40* faster than Prettier because dprint caches results and Prettier doesn't". That makes me want to look at dprint. The "40* faster" figure makes it look like the benchmark is wrong.
The title of the article was and is "Speeding up Prettier locally and on your CI with dprint". If you use the Rust-based plugins instead of Prettier it will be much faster as noted at the end of the article.
To add another advantage of using dprint not mentioned, is that since it's pluggable you can use Prettier and other formatters all from the same formatting CLI. The main dprint repo does this in its dprint.json (https://github.com/dprint/dprint/blob/3d822a48133358ec4e2d5b...)
Also, dprint uses very fast globbing with two threads working together in order to collect files. I would guess Prettier would still be slower if it did this because it's programmed in JS (though not by much), but it doesn't do it.