The answer is really simple: cost and legacy. Thread safety is really resource costly. At the beginnings of windows and even win32 there was no real need to be thread-safe. Neither could I say today that most application do use this feature. In most cases you can reduce the usage of such tools to a minimum just by doing some organisation of your code and logic - and following best practices.
So, I think it is most likely a good approach to let coders decide when to use these features, than spending wealth of resources on nothing.
The problem with MFC is, that it can hardly evolve. It would use the strength, if such resource-costly things would become default. Thus you will miss some really fancy features, that are already present in other frameworks and languages...
In .net, at least, with features like anonymous delegates and lambda expressions, I think it is really not hard to do it, when needed (see
this good article[
^]). It could be even more simple - perhaps it will be in the future, but that's a matter of syntax or language tools, not of making everything thread-safe by default.
Submit an article or tip