The lines are certainly blurring a little these days. You have the ControlLogix platform, for example, that splits the motion task between the 'PLC' and the 'motion card'. The plc does the course trajectory planning at a 2msec update rate and the motion card interpolates between the course updates and does loop closure at 250usec. Neither can perform 'motion control' without the other.
That's for 'high bandwidth, precision' moves. And, yes, both 'high bandwidth' and 'precision' are subjective enough that they are almost useless terms. Generally, the slower the move the better chance a plc will have of making it happen.
I think alot of it is based on what each device is intended to do. A plc is intended to do a large number of disimilar task reasonably well. Most people also expect that it will be reasonably easy to integrate all sorts of I/O into the system. Also, while you can get these very compelling scan time specs like 500 usec/1K boolean I don't think they really hold up. I once ran a completely empty ControlLogix 5555 and got a 400 usec scan time. That's all just processor overhead. I don't doubt it could solve the logic at 500 usec/1K. But that would still give me a true scan time of 900 usec. Then you also have market pressure that sets the price/performance point as well as marketing strategies that try to intentionally differentiate one product from another. So to a certain degree the plc is kind of held back so it fits into a clean niche.
A motion controller, by contrast, is intended to do one thing extremely well. So it's designed from the ground up to perform that function flawlessly. This means very high speed I/O comes standard. The operating system is designed specifically to service motion tasks in a very timely manner. Analog I/O is extremely fast compared to plcs.
Again the lines are blurring a bit. Many motion controllers can be programmed to solve general purpose logic. But these are secondary tasks. If the position loop closure interrupt or the trajectory planner interrupt come along the general logic is abandon and the appropriate interrupt is services, period.
And then you have the position loop and trajectory planner as 'firmware' functions. With some noteable exceptions, no plc comes with a true trajectory planner or a position loop fucntion. Sure, you may have a PID. But that will only run every 25 msec, if you're lucky, not the 250 usec or faster typical of today's motion controllers. Then there are thinks like built-in coordinated motion, dual loop closure, multiple feed forward paths, high order noise filtering, etc. Granted, you could write this all into plc logic. But even if you knew what you were doing you would end up with a pretty serious scan time. Additionally I think that many motion controllers have either multiple processors or custome ASICs to perform some of the specific motion tasks.
There are also many other things I'm sure I've completely missed. But this may get the discussion rolling a bit.
Keith