Some real world examples I've seen where people have screwed up because of not understanding theory:
A graphical toolkit system that stored all the styles applied to components as a linked-list, but each element included a pointer to the the head of the linked list and everytime a new component was instantiated it was added to the head of the linked list. Which meant that creating a new graphical element went from O(1) to O(N) and caused significant slow down (i.e seconds of time).
A well known open-source xml parsing library which stored the attributes of an xml element in a linked-list, as part of it's xml validation it had to ensure attribute uniqueness and do that it had to iterate through every attribute. This means that to insert N attributes would take O(N^2) - again enough to cause a significant performance degradation.
I've seen cases where people who with degrees in CS have screwed up in equally bad or even worse ways.
Writing software is complicated and it's difficult to remember exactly how every part of a large system is working. Sometimes people forget an important detail and end up write code that performs badly. It's hardly limited to people who don't understand CS theory.
As a selt-taught developer, I know what Big O notation is and I've worked with many CS grads (including Stanford) who did not take into consideration algorithmic efficiency.
I think these kinds of examples are very anecdotal.
The bigger point is that it's almost all anecdotal - the number of people in this field is too broad and varied to be able to draw any substantial conclusions about anything, imo.
Was that because the author had no comprehension of complexity and couldn't understand what was wrong with the design, or because of a lazy oversight that was fixable once the problem was brought to light?
A graphical toolkit system that stored all the styles applied to components as a linked-list, but each element included a pointer to the the head of the linked list and everytime a new component was instantiated it was added to the head of the linked list. Which meant that creating a new graphical element went from O(1) to O(N) and caused significant slow down (i.e seconds of time).
A well known open-source xml parsing library which stored the attributes of an xml element in a linked-list, as part of it's xml validation it had to ensure attribute uniqueness and do that it had to iterate through every attribute. This means that to insert N attributes would take O(N^2) - again enough to cause a significant performance degradation.
Iteration through hashtables.