is there any good reason to avoid Node.js for traditional web apps
Yes, if you have N years in web platform X then clearly you can developer an application in platform X faster.
If you want to do Y and platform X has a pre-made solution Y that does X then do so.
All the generic reasons of why you should use one platform over another.
the sort of CRUD apps you build for internal business applications?
Yes there are other platform that let you write a generic application faster, ruby on rails comes to mind.
However, that said. I have experience with node and can't claim I would choose another platform over node unless it does a massive amount of features out of the box for me.
Basically it's a simple question of
Does a tool exists that does all of this for me? No, then pick the most convenient platform to write the tool.
There are no solid reasons why node.js is an inconvenient platform (other then "i hate javascript")
What is a Non-Blocking framework?
Explain it like I'm 5: Imagine you want to make a deposit to your bank account. You walk in and notice there is no queue of people waiting line.
The sign over the bank teller says: "Non-blocking teller". You walk up and ask the teller to process your deposit, the teller responds: "I'm busy with another transaction, try again later".
You wait some amount of time, and try again later. You make your own decision if you want to keep trying to get your transaction processed, or not. You try and the 5th time you try, your transaction is processed immediately.
The "Blocking teller" would have told you to "stand in line as a FIFO queue". The non blocking teller says: "try again later". Which bank teller would you prefer to interact with, and why?
Definition: A non-blocking framework provides a service and returns a result immediately instead of expecting the other programs requesting a resource to wait.
In other words: When a client side program makes a call to the framework, the call will always return immediately with whatever response it has for you without expecting you to sit there waiting for something. This guarentee is nice for programmers who don't want to worry about programming around the situation where the framework expects us to wait for 5 minutes.
A concrete programming example: Suppose your framework wants to provide mutually exclusive access to a file saved on the server side. An example of a "non blocking call" would be try_lock. If the client side wants access to the file, the framework responds: "No, try again later", rather than putting you in a queue and expecting you to sit there waiting.
The client side keeps trying for the lock, until it gets it, once it gets it, it does its business and unlocks it. The benefit of this is that whatever you try has an immediate effect.
Drawbacks to non blocking frameworks: When there is too much work to be done for a non-blocking framework, clients are denied, and fairness is not enforced, only the clients who badger the server the most get access to the service. It's not fair.
Best Answer
Let's immediately get the Turing-completeness disclaimer out of the way and say any language can probably approximate any runtime feature of any other language. Good? Good.
The main difference between the Node.js approach and a Python threaded-server (or a typical Java HTTP server implementation) is that Node.js is single threaded while the latter two are multithreaded. More specifically, the latter two will typically dedicate one thread per request. If, in the handling of that request, you need to do something slow like read from harddrive or connect to a remote database, the thread will sleep until the slow thing is done and the rest of the business logic is ready to proceed. In contrast, the Node.js approach is to schedule callbacks that are to be invoked once the slow thing is done; Node.js' single thread is never sleeping except if there are literally no requests to process.
The main difference between Node.js and PHP is that in Node.js, the code runs in a persistent context that exists as long as your Node.js server is running. So for example, if you write a value to a global variable in one request, and then read out the value of the global variable in another request, the read will see the value that was written by the write. In contrast, in PHP, a new context is created for each request, and so writes to globals in one request are lost when the script handling the request terminates.