check out cypress psoc 5. They have a small CPLD build in and you easily can create the driver in verilog

as stuart mentions "combining the two is usually the easier approach in more complex projects: playing each to its relative strengths".

microcontrollers are good for reliably interfacing physical worlds whereas microcomputers are better at data processing, communications and security. higher up the stack, servers are good at data collection, storage, analysis and learning. end user client devices such as phones or pc's are good for data visualization, ui and interactivity.

normally most of my applications are in remote locations so the full iot stack comes in handy for me even when driving servos or other actuators. for instance, i like to have a time stamped record of everything that happens.

a custom arduino sketch can drive a servo motor and/or other actuators in real time to perform a function say fabricate an item independently. Whenever 1000 units are fabricated or whenever a problem occurs the arduino can send a message to linux using a json object through the serial port. linux can decide to take further local action or send the message to remote servers through an api. on the server, trends can be compiled and production compared with that from last season, notifications send eg to suppliers for kanban inventory management. finally on the user phone, one can schedule pick of of fabricated devices for shipping (or make plans to fix  broken processes – remotely hopefully).

it is not a shameless plug, but think a good board for this is the v2 controller from kijani grows. It is a combined linux (ar9331) and atmega 2560 -with multiple shields all on the same board. the 2560 is the same chips as the arduino mega so you get lots of io for
your motors and sensors. the ar9331 is the same chip on the arduino yun and runs openwrt again a very capable embedded linux soc. It also come with a backend platform for logging, visualization, remote control, alerting, video streams. 

Here are some demo urls https://api.kijanigrows.com/app/#/animation/RedVic/ and v2 url https://kijanigrows.com/product/v2-smart-controller/

This helps everything make sense on a system perspective, thank you! I will check out your boards.

Thanks for the detailed information, this helps me understand the difference between a Linux-type operating system running on a processor and a dedicated real-time MCU.

Either one of these can be offloaded of the real time task of generating the servo timing by using a PCA9685 servo driver board, which can take care of 16 servos for about $2 from ebay. 

in order of best solution to worst - "what you have on hand" "as simple as possible" "complex" "complicated"

in this case arduino would fall under "as simple as possible" but if you dont have an arduino, "what you have on hand" trumps it.

That's a good philosophy :)

I would go with James. Not hard to use an Arduino especially with a DRV8825 driver board. You can use the timer libraries or code them directly for speed control. If your not using a stepper driver board then you will be responsible for PWM, speed control and current control (I would suggest you don't go there!). If you need high speed (depends on your motors but say more than 500 pps, you will need to consider ramp up (and down), otherwise called motion control. Have fun.

Have a look at our project Bela which is a cape for the Beaglebone Black. Price is a bit higher than a microcontroller or RPi by itself but the extra capabilities are definitely worth it if you're after low latency synchronous processing of sensor and audio streams. Our hackaday page is here https://hackaday.io/project/20189-bela-open-source-audio-and-sensor-processing and this is a great post about controlling 20 stepper motors in synchrony: http://blog.bela.io/2017/02/27/axis/

The last time I did something like this I was driving stepper motors driving a scanner that scanned the soil surface on an 8 x 32 foot soil table under a rainfall simulator. I used MS-Dos, Turbo C on a 386 to capture the image of a laser line shone straight down on the soil with a camera set at 45 degrees to the laser.

The x, y, z gantry  stepper motors were driven by a 68HC11 running FORTH that sent individual pules to FETs that drove each one of 4 stepper motor windings. There were 3 interrupts on a second 68HC11 reading shaft encoders after I found I was missing counts trying to both on one board. It was only 3 or 4 in 1,000,000 but that didn't suit me or the boss. When I move the gantry back to 0, 0, 0. I was criticized when the answer was 0, 2, -1.

I once when to a meeting called "Running multiple time critical processes on a single microcomputer"  An extremely knowable engineer talked for about 30 minutes on the pitfalls of  time critical interrupts and then told us only run one time critical process per CPU. He pointed out that if there is more than one time critical process sometime in the products lifetime someone is almost sure to create a condition that one of them fails to make deadline. He work was with computers that were human life sensitive.

Distributed computers networked together running on hardwired heart beat using a real time CPU board for the servos and a second for the shaft encoders is the safest way to control latency, jitter, missed steps, etc. The boards they use for automotive ignition and fuel injection work well as the the real time computer as their timers are first class. They usually have a CAN network built in as well. Once CAN is set up and running it just works and works fast. For most things SPI or a well thought out RS-485 network  is fine. 

How you pass out messages to move is critical as well. The real time system should alway have a place to go that is in time with all the other axises. 

If you have jitter, chatter or any other uneven motion speed up, slow down, but find what is causing it and fix it.

It depends !

There are a few tricks and "best practices" to do "real time" on the RPi, which I use to drive image data in #Rosace with 1KHz streams without visible artefacts.

The rest is a matter of : do you need cheap/convenient/fast/ample storage/processing/communication ?

You can develop straight on the RPi and you can log in through SSH to test your code directly, even debug and step through it. Having the compiler directly in the platform is a fantastic advantage for the next time you have to update your system, as you don't need to reinstall all the tools on the computer of the moment and recover the source code.

If you want to cut prices, you can develop on the Pi and move to a cheap microcontroller later, once your algorithm is ready.

Unless you need the Raspberry Pi for other things, the Arduino is a better fit for motor/servo control applications. While the Pi can do the accurate timing necessary for that (see http://abyz.co.uk/rpi/pigpio/index.html), you'll get there quicker with the Arduino.