Avoid. There are so many great resources out there that show you how to implement simple fluid solvers while teaching you something physically relevant.
For example, with respect to compressibility, the author isn't saying that water isn't compressible in the physical sense, but rather that it's not compressible in the mode of its behavior in their prior example (which they refer to as a "Naïve Implementation"). Which they're correct about -- their naive implementation would be more like an ideal-gas at near-vacuum pressures, which would be pretty unrealistic for water under normal conditions. And they also explain that non-compressibility (in the physical sense) is merely an approximation.
Then as for pressure-differences, the author has stuff like a variable called "difference_in_p" and writes about the pressure-field and such. So, no worries, they're not actually confused about incompressible fluids being able to have pressure-differences.
You are right that they typo'd "Navier-Stokes equations" in two different ways: they always seem to miss the last "s" in "Stokes", and sometimes they non-idiomatically put Stokes's name before Navier's. Presumably the author should fix the spelling of Stokes's name -- the latter might be a stylistic quirk (sometimes folks may intentionally re-order a list of names, arguing that it'd be more fair that way).
All that said, I can appreciate how it might be odd to see common terms used in a conceptual-development in a manner inconsistent with their meanings in the standard literature. It might be helpful for the author to include something like a disclaimer that they're taking a constructivist approach, and that the terminology used during construction may vary from the final definitions one'd arrive at once the standard theory is constructed.
Neither of those should doom a computational project, but I think they have a bigger negative impact on readers than the author realizes. My 2c.
Starting instead with "here's how I imagine diffusion" from scratch reads like an introduction to homeopathy: "why, you have a bloated belly that feels hard, then you need to drink a (properly diluted) solution of some hard substance, say granite".
The result simply is, as I stated, that the interested reader will not have learned anything physical about fluids, and will not even know the vocabulary to dive deeper afterwards.
Note also, that the “naive” way still requires you to understand the divergence of a vectorfield, at which point the whole approach collapses and I wonder why they don’t simply give us the equations and then we can see for ourselves.
I'm so tired of this attitude.
If you write a 10 page article about using some-framework-or-other, and you invent your own terminology and can't even be bothered write the name correctly of what you're writing about, that's not a good sign in my book. Doesn't matter when it was invented/developed/released.
And that's on top of the plainly wrong statements in the article.
I happen to be a technical artist, and the first rule of technical art is: cheat. If this upsets physicists and mathematicians, they completely miss the point of the entire endeavor.
Math and physics are merely tools to achieve the end result, not a goal unto themselves.
I'll take a wild guess here that your technical artistry isn't in the field of fluid mechanics. There is a whole, very mature, very developed, field of fluid dynamics for visualizations out there. Just check out what people present at SIGGRAPH every year. It's amazing. They know exactly what they're doing. The thing with the visualization of many physical systems is that humans are really good at spotting discrepancies, e.g. if things don't bounce off well, or the smoke looks like honey - then it just looks really bad (like my blended face drawings) - but producing bad results doesn't automatically make me a great artist.
[1] https://www.nasa.gov/centers/langley/news/factsheets/windtun...
These notes became the book, "Fluid Simulation for Computer Graphics".