The theory
To me, just like to several other responders to your question, this is first and foremost the question about algorithmic complexity. The program from Eco's book generates all permutations of the 4 letter input. There are actually two types of permutation generators: with and without repetitions. The difference matters because there are much fewer permutations without repetitions:
No of permutations No of permutations
N without repetitions with repetitions
1 1! = 1 1^1 = 1
2 2! = 2 2^2 = 4
3 3! = 6 3^3 = 27
4 4! = 24 4^4 = 256
5 5! = 120 5^5 = 3125
6 6! = 720 6^6 = 46656
7 7! = 5040 7^7 = 823543
You probably know that both N^N and the factorial function N! grow very rapidly, so rapidly in fact that as N grows both will quickly overwhelm the processing capabilities of any specific computer, even a modern one. From the table above you can also see that N^N grows quite a bit faster, although the difference for small values of N can be not very dramatic.
How does this relate to the presented programs? Both of them output the number of permutations without repetitions. For 4 input letters, both programs need to produce 24 outputs, but they approach it very differently. The program from Eco's book tries to exclude invalid combinations as early as possible. E.g. once it identifies that I1=I2, it skips all possible values for I3 and I4, because they are deemed to be irrelevant. How successful is this strategy? Maybe it can be assessed by thinking about how many times the innermost IF statements are executed, see lines 80 and 90. It is easy to check that they are executed only 36 times, i.e. they only result in a GOTO executed once out of every 3 iterations.
The program that you wrote actually generates all permutaions with repetitions and then selects from them the ones without repetitions. This means that your innermost loop runs much hotter: your IF statement is executed 256 times, which is particularly important because the condition that you are testing is also quite a bit more expensive computationally compared to the condition in Eco's program. For large enough N the inner loop tends to dominate the computation cost and you will be able to a large extent ignore the cost of everything else. For smaller N your mileage will vary. Crudely speaking, your inner loop is up to 256/36 times slower, i.e. slower by the factor of 7.
The computational experiment
How does the theory compare to the actual practice of computations on a small 1980s micros? Well, this thread already contains plenty of evidence:
I am not including measurements by Maury Markowitz because he included the user input time into his results, which makes them unreliable, esp. given how quickly the programs run. I also did a quick run of both programs on ZX Spectrum 48K, and found that Eco's program runs in 1.48 sec and your program runs in 7.84 sec (clearly, the inner loop estimate is a bit less accurate in this case, but not dramatically so).
However, these tests do not really answer the interesting question: was it worth it for Eco's characters to spend half-an-hour writing their efficient permutations generator, if they could implement a brute-force solution, like yours? To test this, I wrote two new programs for ZX Spectrum BASIC.
The first program generalizes the algorithm from Eco's book to the case of 6 letter permutaions:
10 REM ANAGRAMME
20 DIM A$(6): INPUT A$(1),A$(2),A$(3),A$(4),A$(5),A$(6)
30 POKE 23672,0: POKE 23673,0: POKE 23674,0: POKE 23672,0
40 FOR I=1 TO 6
50 FOR J=1 TO 6
60 IF J=I THEN GO TO 180
70 FOR K=1 TO 6
80 IF K=I OR K=J THEN GO TO 170
90 FOR L=1 TO 6
100 IF L=I OR L=J OR L=K THEN GO TO 160
110 FOR M=1 TO 6
120 IF M=I OR M=J OR M=K OR M=L THEN GO TO 150
130 LET N=21-I-J-K-L-M
140 POKE 23692,0: PRINT A$(I);A$(J);A$(K);A$(L);A$(M);A$(N);" ";
150 NEXT M
160 NEXT L
170 NEXT K
180 NEXT J
190 NEXT I
200 PRINT "T = ";65536*PEEK 23674+256*PEEK 23673+PEEK 23672
Just in case you are wondering: POKEs in line 30 re-set the internal timer, and PEEKs in line 200 read its state after running the code (this allows me to measure the execution time to within 1/50th of a sec). POKE in line 140 is necessary because the number of outputs is quite large, so the POKE ensures that outputs just scroll asross the screen (without the POKE I'd be given a prompt to scroll the results every time the screen gets full, which will make my measurements less accurate).
On my ZX Spectrum 48K this program executes in 4685 frames, i.e. in 4685/50 ~ 93.7 seconds. This is a link to my program, so that you can try running it yourself. Therefore, the characters in Eco's book, who just spent half an hour writing this code, will have to wait for another 1.5 minutes to get the result they needed.
I also implemented your approach for 6 letter inputs, with the same instrumentation. The code looks as follows:
10 REM ANAGRAMME
20 DIM A$(6): INPUT A$(1),A$(2),A$(3),A$(4),A$(5),A$(6)
30 POKE 23672,0: POKE 23673,0: POKE 23674,0: POKE 23672,0
40 FOR I=1 TO 6
50 FOR J=1 TO 6
60 FOR K=1 TO 6
70 FOR L=1 TO 6
80 FOR M=1 TO 6
90 FOR N=1 TO 6
100 IF I=J OR I=K OR I=L OR I=M OR I=N OR J=K OR J=L OR J=M OR J=N OR K=L OR K=M OR K=N OR L=M OR L=N OR M=N THEN GO TO 120
110 POKE 23692,0: PRINT A$(I);A$(J);A$(K);A$(L);A$(M);A$(N);" ";
120 NEXT N
130 NEXT M
140 NEXT L
150 NEXT K
160 NEXT J
170 NEXT I
180 PRINT "T = ";65536*PEEK 23674+256*PEEK 23673+PEEK 23672
It outputs all of the necessary permutations in 137118 frames, i.e. in 137118/50 ~ 2742 sec ~ over 45 minutes. Run it in your favourite emulator, to verify my findings. So, even if you were to write this program in two minutes, as you claimed in your post, you'd still have to wait for quarter an hour longer than Eco's characters just to get the necessary outputs computed.
Summary
Interpreted BASIC on the 1980s microcomputers was slow enough to justify having to use the correct approach to generating permutations without repetitions, esp. in the case of 6 letters.
Fundamentally, the difference in the number of permutations with and without repetitions is so large that it would make a difference even on the modern desktop PC. You won't notice this difference for a small number of letters, but for larger values of N, the computational complexity will once again dominate the proceedings.
