Formal methods is the name for the techniques of mathematically proving that programs do what they're supposed to. A perfect program will therefore remain perfect forever. It would be nice if formal methods were more widely accepted, because as programs grow larger and larger the interspersed bugs make them more and more unreliable. But formal methods slow the pace of program development so much, and fit so poorly into the messy but productive real world, that they are used only rarely even in potentially life-threatening systems. This is just a corollary of something all programmers know, namely that it is often easier to write an inefficient program than an efficient one.
Assertions are the ultimate in inefficiency and writing ease.
Prolog proponents have long used these same arguments, since Prolog makes it easy to concentrate on the spec and leave the implementation up to the compiler. But this approach misses the fact that much of the necessary creative work of programming is in coming up with a good implementation, not just in making a spec. Practical Prolog programs address implementation issues too, with the result that while a Prolog program is shorter than a typical imperative one, is still much longer than a proper specification. All tend to use mathematical thinking and the notation of first-order logic to achieve concise specifications. A simple program is handily specified using such assertions, statements about the state of the program's variables before and after the program runs.