Typically I'd just downvote, but was that condescending comment really needed? This is the sort of toxicity that turns people away from our community.
Given that you do not possess the prerogative to control the costs of your potential mistakes, ought not calls of toxicity be restrained toward obvious cases? Also, how toxic are mistaken accusations of toxicity?
A condescending comment would be something like: "Maybe you should stick to your pretty R graphs for 'journalism' and leave discussion of software engineering to the professionals who actually get paid to build systems and who haven't, as a profession, fucked up on every metric in the last decade even without including the most recent election."
That would be a condescending comment--the one you are remarking on can be interpreted as "hey, designers get to make pretty things unfettered by layers of shaky abstractions and stupid imposed by business and deadlines".
Please don't rush to aid the theoretically aggrieved; especially when there are folks in this same subthread going "yep, as a designer, that's the truth".
As a programmer, you gotta get all the little details right or the application is not possible to use. There is no way around it, whatever is forgotten will just hit you right in your face.
And last but not least. Drawing is dead easy. A programmer could design a UI in a drag&drop devtool maybe as fast as a designer. The challenge when creating an application is not the drawing of the UI but the handling of the user interactions and the data.
First of all a designer doesn't get to live exclusively in photoshop or some other tool. They don't get to ignore the "reality of usage". In order to be a competent designer they have to not only completely understand the problem domain, but also the given software solution and how a user can use the software to achieve the desired goal in the most concise manner. They have to worry about how to signal to users how to perform any given interaction and the overall complexity any activity has. Also they absolutely do test designs with real users. There is like a whole field of study in design around exactly this.
As to your last point, drawing != designing. Designing is actually really hard. This is a problem I see with programmers all the time. The oversimplification of others contributions. Yes you can put together a UI with drag and drop tools. You can build a website with drag and drop tools too and you'll probably get the same quality as the drag and drop UI. A drag and drop design will probably have most of the various pieces. But will it be obvious what actions a user can take from any given screen? Will it properly optimize screen space, and be color correct? There are a 1001 questions that a designer has to ask that most programmers wouldn't even think to ask. There are many challenges when writing an app, and good design has proven over and over again to matter just as much to the success of a business as solid code.
First paragraph. I could say all the exact same thing about a developer.
Second paragraph. Yes to all your questions. I should clarify that the drag&drop tools I had in mind were for desktop applications, not web, that's a different world.
Also, design in the context of a team especially ought be perfect, because your perfection will be degraded in a game of telephone.
By perfect, I don't mean that your design fits the user with maximum optimality. I mean that when you draw a box, you actually mean a perfect box. When a mathematician draws a square, they are describing a perfect square. It would be a little socially blind to pick up a magnifying glass and accuse the mathematician or the designer's square to be imperfect because you find the bumpy ugliness of a 1080p monitor or a sheet of paper.