OSNews

I think this (clearly) subjective comparaison
Clearly. It's a marketing piece as much as anything else. However, it was written by someone who knows a lot about C++, and as somebody who has also used C++ a lot, I agree with him.

He talks about garbage collection. In C++ you can also use GC
You can, but not very good ones. The language semantics don't let you use high-performance generational GCs, just lower-performance conservative ones.

but you have the choice not to use it (which is very important).
Not using the GC is an optimization that should only be made when profiling shows you that you're spending too much time in the GC. The default should be GC on, with manual management possible (which is what some Dylan implementations can do). Instead, C++ use manual management as the default, with GC possible. This shows in the fact that large C++ projects, to this day, suffer from memory leaks. Mozilla leaked like a sieve until well into the 1.x series, for example.

But it's often irrelevant, since you almost never need to allocate memory yourself in C++ (see my upper comment).
This isn't really true. If you're programming something like a GUI, where you need polymorphism, you have to store pointers in STL containers, so you lose the memory-management benefits of the STL. You could store smart-pointers in the STL containers, but then you're back to a primitive GC, one that is slow and not transparent to the programmer. That's just the ideal case. In practice, you have to deal with code written by people who do not use modern methods, and memory leaks and corruption become a fact of life.

He's clearly ignoring references in C++, which accomplish most of what he says about '=' in Dylan.
References don't do the "right thing." In particular, they are not first-class, so you can't do things like store them in containers, etc. Like many C++ features, they are a partial solution, not a general one.

He's always saying Dylan is better 'cause you can make a mistake such as with feature X in C++.
It's not just a matter of being able to make mistake using feature X, but people making mistakes often enough that a C++ luminary had to write a book about it.

Again, in C++ you have the choice to use that feature X when you actually need it.
In a lot of cases, you don't have that choice. If you actually read all 50 of the points, you'll see that the majority of them have nothing to do with pitfalls of specific features, but general aspects of the language that you have no choice but deal with.

Take, for example, #22: " Pass and return objects by reference instead of by value." Every time you write a function declaration in C, you have to choose between reference semantics or value semantics. If C++ gurus tell you to always choose reference semantics, why does the language default to value semantics? Choosing how to pass values isn't an optional feature --- you have to make the decision each time.

Or, take #14: "Make destructors virtual in base classes." You don't really have a choice whether to make a destructor virtual --- if there is going to be a derived class, it needs to be virtual. It's not a choice you can make, just another thing you can accidentally forget.

Again IMHO, most of the time, people are taking C++ from a pov that is too low level.
Aside from the memory management bits, none of the points have anything to do with a low-level view of C++. In any case, the actual advice was written by Scott Meyers, who isn't exactly a C++ dinosaur.

This kind of attitude doesn't to see the philosophy of C++ "what you don't use won't hurt you";
That's the thing --- what you don't use *does* hurt you. C++ is full of little micro-optimizations at the language level, and compromises for dumb optimizers, and you have to be aware of those micro-optimizations in all code you write. Why else, for example, do methods default to being non-virtual? So compilers don't have to do virtual-dispatch elimination. Why are their multiple forms of delete? So compilers don't have to elide object headers. Why do the default copying-semantics leak memory in a language that generates tons of copies behind your back? When you initialize a member in the class declaration, why can you only use constant-integer-expressions? So the compiler doesn't need to execute code during compilation. Why do you have friend functions? Because they had to hack around the "class boundries == protection bounderies" decision, even though the two should have been orthogonal. Why is the "diamond-shaped inheritence graph" possible in C++, and why are virtual base classes necessary? Because without class-hierarchy analysis, dumb C++ compilers would treat everything as a virtual base class, and pay a high performance cost.