To preface, I think there's room for a wide variety of meanings people assign to words and nobody has a monopoly on what "engineering" means. That said, I offer an alternative:
Software engineering = programming that accounts for real-world _constraints_ such as performance goals, technology limitations, monetary budgets.
Whether engineering a bridge or engineering a circuit board, they share a common theme of optimizing multiple constraints (materials, cost, maintenance, durability, etc).
An advantage of this view of engineering is that it can also be applied to solo programming. The single programmer weighs the tradeoffs to a possible solution.
The other concept of "add time and other programmers" that the blog author is talking about is also important but in my opinion, I'd prefer the industry find another catchy label for it. I've seen others call it "software factory design" instead of "software engineering". The "factory" of optimizing how multiple programmers work together is what books like Mythical Man Month, Peopleware, etc talk about.
To apply my concept of engineering (constraints) back to the Go language... let's say I interview a candidate and ask what his favorite language is and he says "Go". I then follow up and ask "Ok, Go is good. What is Go not good for?" If he responds that he can't think of anything negative, it means he can't do engineering with Go. Engineering means you know the stress weaknesses of concrete, or corrosion properties of steel, or the warts of programming languages. If the candidate then tries to answer with the universal "well, good and bad programming can be done in any language", that's just a restatement of the Turing Tarpit[1] and you can't do effective engineering with that view. Assembly, C/C++, Haskell, Lisp, Javascript all have weak points that work against particular engineering goals.