Personally, I think the C community is deeply infatuated with the idea that "we are in fact simple" mentality even though it's not well justified.
C isn't simple. C isn't simple to use.
On the implementation side, it has a complex calling convention. It relies on a memory management runtime without spec'd behavior. Tons of hardware implementation details leak up to the upper levels. C's error handling schemes are inconsistent, and thus complex to work with and to implement.
Being a C programmer isn't much easier either! C's memory managers tend to blow up if misused, but they don't blow up WHEN they're misused. They always cause problems, but it's not clear how or why. You have a bomb in your code that will go off in a random place. Even good debuggers with great tools can find it challenging to find the source of a double free. And that's alongside managing the weakly typed (not to be confused with static/dynamic) world, the pointer arithmetic, the inconsistent library conventions. Oh yeah, the libraries...
C's libraries aren't simple. They have to protect themselves from double inclusion, they can collide with each other, and have wildly different conventions depending on if they're loaded at runtime or compile time. Despite a constant derision of OO from the community, they often affect an "OO" discipline on methods. In reality this asks developers to create the impression of OO behavior by being very (very!) careful with call sequencing. And of course, the price of failure on most of these tasks is at runtime, on someone else's hardware, often with opportunities for remote execution.
When a C programmer says, "C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex," we have to read it very carefully and ask, "What does simpler mean?" Because despite the complexities of being a C programmer and the unstated complexities of the C runtime (and the large portion of unspec'd behavior so glibly ignored in this article to dunk on Rust), they still say "C is simple."
In this case, evidently it means: "Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible."
Go isn't simpler. Go actually aims for a rather broad category of programs (it goes way up into the world of abstraction Python covers, and stops short of the embedded world where C is firmly entrenched because it's well-understood). Go has a sophisticated (and arguably, hard-to-use) concurrency model (didn't the author just say, "Concurrency is generally a bad thing?") and implementation. It has real garbage collection. Its stdlib is expected to have full SSL and networking support builtin.
But Golang is familiar to C programmers. I think that is why we see all the dunks on C++ and Rust in this artcile. C++ and Rust are weird. They're different. Go feels like C, so it's "simpler to learn" even if it requires a whole lot more core concepts and careful implementation than a C compiler.
Maybe Rust isn't your solution. Okay. Maybe C++ isn't your solution. Okay. There's still lots of other good languages to try. Languages that don't ask users to wade among a field of charged rails that the slightest touch can result in catastrophe. Nim or D maybe? There are others, and you can find them.
But continuing to use C with the attitude that, and I quote, "I don’t really care. In light of [the complaints leveled at Rust], I’ll take my segfaults and buffer overflows" is dangerous. It's unprofessional. It's reckless. It's also a false dichotomy.
The answer to C's problems is to stop using C. Not to start using something else specifically. This article makes it clear that the actual goal of this sentiment in the C camp is to keep using C. There isn't even a candid ownership of the problems with that strategy.