I fall to see how "programs may be nonportable" and "implementations may define language extensions" seems to imply "the existence of UB as an optimization tool is bad," as you seem to be arguing.
Rather than try to design a language specification that fully describes all of the constructs that programmers may need to accomplish everything they need to do, the authors of the Standard wanted to encourage variety among implementations, by allowing implementations to process many actions in whatever way would best serve their individual customers' needs. When the Standard says some construct invokes UB, that means nothing more nor less than that the Standard waives jurisdiction. Because the Standard makes no effort to mandate everything necessary to make an implementation suitable for any particular purpose, failure to mandate something does not imply any judgment as to whether or not implementations claiming to be suitable for various purposes should, as a consequence of that claimed suitability, be expected to process it meaningfully.
The as-if rule agrees with you, unless and until UB is involved. At which point, the as-if rule frees the implementation from any and all requirements. This is the basis for a number of optimizations, the ability to assume a program does not contain undefined behaviour, because the negation of that case permits any results.
An optimization predicated on the assumption that a program won't do X may be useful when a compiler is used for tasks that don't involve doing X, but worse than useless for tasks that do. If some tasks require doing X and some don't then those that don't involve doing X may be usefully processed by an optimizer that assumes the program won't do X, but those which would involve doing X should not be "optimized" in that fashion. The only way a set of optimization rules could be appropriate for all tasks would be if it provided an easy way for programmers to indicate when a compiler must allow for the possibility of their code doing any of the things it might need to do, and when no such allowance is necessary. When the Standard was written, however, it was expected that programmers would select and configure implementations in whatever ways would be suitable for whatever tasks they needed to perform, rather than trying to indicate particular requirements within the source code itself. If the Standard were to specify constructs that programmers could use to indicate their requirements, then reliance upon such extensions without the use of such constructs could be deprecated. Responsibly deprecating something, however, requires that one first acknowledge it and provide a replacement--something the Standard has yet to do.
Yes, I know that UB is the candidate for compiler extensions, and if you know you have a particular compiler extension, you may exploit that, but absent that, my statement applies
One problem is that many compiler vendors never viewed the fact that their compiler would process something the same way as every other C compiler that had existed before it as an "extension", and thus saw no need to explicitly document it as such, even if the Standard neglected to define the behavior of the action in question but couldn't imagine any reason why a quality compiler wouldn't process the construct meaningfully anyhow. For example, given a structure like:
struct S { int x[4]; } s;
Although the Standard would allow an object of type struct S to be used to access the stored value of an int, the way N1570 6.5p7 is written does not allow the use of a dereferenced int* to access the stored value of a struct S.Of course, the ability to include arrays within structures would be rather useless on a compiler which would use N1570 6.5p7 as an excuse not to recognize that s.x[2]=4; which is a dereferenced int* equivalent to *(x+2) might access the stored value of a struct S, so compilers pretty much unanimously extend the language to support constructs of that form, but I don't think I've seen any that document that "extension".
Also, it may be worth noting that if Q is a conforming compiler, and L is a program that is processed by Q in conforming fashion, and that exercises the translation limits given in N1570 5.2.4.1, the following would also be a conforming implementation:
If input I matches L
Process program L using Q
Otherwise
Behave in arbitrary fashion
Judging from the Rationale, I don't think the authors of the Standard would have intended that such an implementation be considered non-conforming: "While a deficient implementation could probably contrive a program that meets this requirement, yet still succeed in being useless, the C89 Committee felt that such ingenuity would probably require more work than making something useful." I think the Committee overestimated the difficulty of contriving an a conforming-but-useless implementation, but I think it's abundantly clear that the Standard makes no real effort to mandate everything necessary to make an implementation be suitable for any particular purpose, or even any useful purpose whatsoever.