I think this is a fine page and it is eminently reasonable that sqlite remains a C codebase. In particular, I think he's right that rewriting sqlite in a memory-safe language would introduce a bunch of bugs and likely result in a couple of years of instability.
But the "security" paragraphs in this page do the rest of the argument a disservice. The fact is, C is a demonstrable security liability for sqlite. The real position of the project is that memory safety security vulnerabilities are an acceptable tradeoff for an otherwise reliable database engine; in practice, people will deal with the exposure either by treating it as an externality (ie: baking sqlite into products where it is directly exposed as part of attack surface, and then throwing up their hands and issuing patches when RCEs are discovered) or by carefully positioning sqlite so it isn't a meaningful part of the attack surface.
Both of these approaches are suboptimal --- that's why we call them "tradeoffs" --- and it is the case that if you held everything else equal (and you can't, but bear with me), sqlite would be a better piece of software written in, I guess, Rust; memory corruption wouldn't be one of the problems you need to consider (or blow off uncomfortably).
Again: the argument as a whole, and this page --- fine! I use and like sqlite.