I honestly never got why in college his opinions were just taken as mandates. I never bough into the "goto considered harmful" argument, for example.
That is one of his least important contributions, though it was important, because at the time when it was written, even if better programming languages existed, most of the programs were written either in COBOL or in FORTRAN and using ad hoc program structures implemented with a lot of GOTO instructions.
Several years later, there was a series of articles as a reaction to the misguided extreme interpretation of the title put by an editor to the article written by Dijkstra, i.e. the interpretation that GOTO should be avoided completely. Such articles were written by people like Zahn and Knuth and they demonstrated that while unrestricted GOTO is dangerous and unnecessary and it should not be allowed, a restricted form of GOTO (i.e. jumping only forwards and without entering nested blocks) is absolutely necessary if maximally efficient program structures must be implemented. Those conclusions from the early seventies have become even more relevant today, because when essential GOTOs are removed from a program structure, that is possible only by adding extra Boolean variables and extra conditional branches (i.e. "if" or "while" statements), which can be mispredicted, so their cost is many times higher in modern computers than it was in the computers from a half of century ago.
The language Xerox Mesa was designed according to the conclusions of those articles, so it included a restricted GOTO. Unfortunately, being a proprietary language of Xerox, Mesa has not seen widespread use, even if it was superior to most of the languages designed later than it.
Far more important contributions of Dijkstra are that in 1960 he taught everybody how to implement recursive functions and procedures and also how to allocate the parameters and local variables of the ALGOL 60 blocks, using stacks, stack pointers and stack frames, and then in the following years he taught everybody how to implement mutual exclusion when concurrent processes access shared resources.
In computing science it is hard to say with certainty who invented first some technique, because many of the early uses of some programming techniques have never been published.
Nonetheless, if someone had discovered earlier some programming trick and they kept it to themselves, that does not really count, what matters is only who published first the technique, teaching everybody how to use it.
Dijkstra is certainly the one who popularized during the sixties and early seventies many of the programming techniques that are now among the most fundamental and which are now implemented in any operating system, in any compiler and in any executable program.
Other examples of people with similarly important contributions to programming are John McCarthy and C.A.R. Hoare. As a coincidence (or not), all 3 were supporters of allowing the procedures and functions of ALGOL 60 to be recursive, as there was a camp who wanted to prohibit recursion, fearing that allowing recursion may lead to complex and inefficient compilers and executable programs.
idk how old you are, but there there was a style in the 70s where goto was the only control flow operator used in a lot of codebases, and it was absolutely horrible.
He was a proponent of a style of programming that was reasonable... you could reason about it and prove / demonstrate that it is doing what it should within that block of code as being correct.
Imagine teaching someone BASIC or FORTRAN...
Or for something more complicated... https://github.com/ArthurFerreira2/STARTREK/blob/master/star... ... and arguably, that's well structured (its not doing a GOTO into the middle of a subroutine... I think). Tangent to that source code https://meatfighter.com/startrek1971/ for a port to C# (with line numbered goto).Dijkstra's approach to programming help take software development from a craft where each woodworker did things their own way and going from one shop to another meant relearning everything to something were one could more easily reason about how an application worked by removing some of the ability to write unstructured code. You can still write it... and I'm sure you can find some code that is convoluted ("... the determined Real Programmer can write FORTRAN programs in any language." https://www.ee.torontomu.ca/~elf/hack/real-programmers.html ).
Structured programming is also easier to teach. Yes, you can teach people how to write line numbered BASIC but the challenge is also teaching them discipline to not cut off their fingers when doing it. The structured programming approach it becomes easier to enforce that discipline as part of teaching ... and if they go and do dangerous things after they graduate from college, that's up to them.