I think it's reasonable because there are very rarely any such things as standards in software development. Municipal building codes are standards. Drug testing regimens are standards. Programming languages are not standards. At best they are conventions, and only insofar as certain niche subset industries are concerned.
As for de facto standards, I don't think we should be paying much attention to them. I think it's very important to draw the distinction that software development currently has no standards (you might be able to argue for TCP/IP, where alternatives are only ever used because they fulfill some unique use case not covered by TCP/IP), because for as much as we want to call this industry "software engineering", we sure as hell don't treat it like any other field of engineering, for many of the reasons already mentioned.
I think the first step is to sit down and agree on some terminology. You can't even get two programmers to agree on what "Object Oriented Programming" means. No wonder we aren't treated like professional engineers. We don't act like them.
Most "industry standards" are de facto standards. We're not talking about laws here, or even open standards like C or Common Lisp. An industry standard is simply a widely-accepted practice, which is perhaps defined by the fact that it would not usually be questioned by a casual observer from that industry. Painting interior walls some shade of off-white is an industry standard. Using Python for scripting and application logic is an industry standard in the same way.
I wouldn't say that using Python for scripting is even a de facto standard in that sense. Don't make the mistake of assuming your experiences are normative.
As for de facto standards, I don't think we should be paying much attention to them. I think it's very important to draw the distinction that software development currently has no standards (you might be able to argue for TCP/IP, where alternatives are only ever used because they fulfill some unique use case not covered by TCP/IP), because for as much as we want to call this industry "software engineering", we sure as hell don't treat it like any other field of engineering, for many of the reasons already mentioned.
I think the first step is to sit down and agree on some terminology. You can't even get two programmers to agree on what "Object Oriented Programming" means. No wonder we aren't treated like professional engineers. We don't act like them.