> but later in the code it was important that the value was actually 5 and not "5".

The bug was in that part and not in previous if(5=="5") part. Issues like these appear when Java programmers start to code PHP as if it's Java.

I agree - in fact the problem was solved by removing some unnecessary type-checking code.

The point I was trying to make is that it's easier to learn the basics of types and logic in a strict system. Implicit type conversion and polymorphism can easily result in misunderstandings when you've just started learning to program.

"Easier" is (usually) the enemy of "better".

Again. These are classes for _beginners_. I'm not suggesting that you should never learn these things. They should also learn functional programming, estimating how algorithms perform, concurrent programming, binary trees, and a few hundred other things. But Programming is not something you master overnight.

You need to understand that 2+2=4 before you can understand that 2+i^2=1.

You are correct, but in that case it's not the question of what is easier, but what is necessary. "Easier" implies that there is a choice between comparable options, not that one is the prerequisite for the other.

Yes, but using === would have identify such bugs by causing failure of the test rather than running the code for "is true" and getting odd results. The conditional code simply not running will often make the bug (one of the values not being of the expected type) easier to trace than a calculation resulting in 51 instead of 6 ("5"+1 rather than 5+1) at some point later.

You can fix such a bug in two ways: "manually" coerce the values when used, or make sure they get converted to the right type as early as possible. I find tha ltter, along with using === except where you really must have a more flexible comparison, to be the better approach. And if I mistype and skip a = I end up with == instead of = (which would cause a different class of bug!)