:I am sorry if I was not careful in reverting your edit. Since you really altered the article in the fundamental way, I can't do anything but revert. But I hope you do realize that you also remove some points, which is not nice either. Since your new version in the page history anyway, we can work on it together. If you think what I did is childish, (though I think that's just usual procedure in wikipedia), then so is yours maybe. (Though I might not have time after Easter) 

 :Anyway, to get to the point, my point is not we should avoid the matters that are the source of dispute. And I don't disagree that we should mention how to make points on what. Indeed this old version says it is a bad practice to use assertion to do error checking. What I am saying is that we have to say this before saying why some code has assertions and some don't. That is, we are giving the reasons why assertions are often removed. 
 :(1) Assertions may slow the program. 
 :(2) Since assertions are usually not used for error checking, it is usually expected that the removal of them does not change the semantics. 

 The mention of how per se is ok, but the problem is the way it is said. Now let's go back to your version. How about this one: 

 :Using assertions is often considered good practice. 

 This may be true or may be not. But what is the point of saying this? I like sentences like "Assertions also simplify debugging: if an assertion no longer holds, the programmer would like to be informed immediately." In short, why do we concentrate on how programmers use assertions (e.g., simplifying debugging) instead of how they should use (e.g., using assertions is good.)