This article is a junior engineer’s idea of what a senior engineer should know.
(Although "this is bad practice, I've never done it, I didn't care to look up details" would be a perfectly fine answer to me if I was the interviewer)
It’s no longer the C++ from 20 years ago.
Raising exceptions in a destructor sounds even more fun than a “return” statement inside a Python “finally” block of a method.
The footgun store will never go out of business!!!
The fact that C++ programming books have entire sections about destructors (see: Effective C++) shows that this is very much not irrelevant minutiae. C++ forces you to deal with this kind of detail all the time.
Now, we can have a much more interesting discussion about whether C++ is a disaster of a language precisely because you are forced to deal with this kind of minutiae by hand. We could also have an interesting discussion about whether RAII is the "object oriented" of our time. We could even have an interesting discussion as to why so many companies ban constructors/destructors in their C++ programming guidelines.
However, irrelevant minutiae C++ destructors are not.
Although, I guess if you only statically allocated everything once at startup, you could use constructors without destructors? Presumably using the placement versions would also let you use constructors without destructors.
I'm generally talking about systems that are <64KB. You basically don't get heap and determinism is really important.
Chapter 2: Constructors, Destructors, and Assignment Operators
Item 5: Know what functions C++ silently writes and calls.
Item 6: Explicitly disallow the use of compiler generated functions you do not want.
Item 7: Declare destructors virtual in polymorphic base classes.
Item 8: Prevent exceptions from leaving destructors.
Item 9: Never call virtual functions during construction or destruction.
Item 10: Have assignment operators return a reference to *this.
Item 11: Handle assignment to self in operator=.
Item 12: Copy all parts of an object.
No C++ "bread and butter" I have seen so far goes into depth on this subject.
What state are members left in when destructor throws? If exception happens in virtual base? If member destructor throws, what other class members have they destructor executed? will delete[] be called?
The author possibly does not care to know themselves! As you say, totally irrelevant to any normal programming. Unless you are writing clang or gdb