The UBW32 is a very good way to go, from what I can tell of your requirements. It will support exactly what you need, as long as you're OK with 3.3V I/O (some are 5V tolerant, but not all.) It is inexpensive ($40) and is very easy to talk to using any language that can support serial ports (which is pretty much all of them - Basic, C, C#, Processing, etc.)
You can use any of the 76 I/O pins as inputs or outputs. The stock firmware as shipped will allow you to do what you want to do, no programming required on the embedded side. Getting that data up to the PC over USB (at only 10Hz) will be no problem. Getting outputs to go at 1KHz will probably work just fine as well.
If you have any questions, please let me know. I'm happy to help you out.
I don't know the MSP430 in any detail, but have a lot of experience with PICs. PICs don't specifically have a separate register for input and output, but many of them do in practise. The PORT register contains the immediate pin states, for input and output. The LAT resgister contains the last-written values, so I suppose you can call it a output register. If you use PORT for input and LAT for output, then you have separate input and output registers. Just ignore that PORT could be used for output too, with slightly different properties than LAT.
The low PICs from 16 on down don't have LAT registers, only the PORT register. You therefore use the same register for input and output. That's no big deal since reading and writing are separate operations.
There is one wrinkle with this that sometimes catches people, and much superstition-based programming has evolved around it. The issue is that the PORT register always reflects the actual pin states. This may sound simple and harmless, but you can get into trouble when the external circuit holds the pin in the opposite state it was written in. Note that enough capacitance on the pin will do this, at least for a little while.
This becomes a problem when you perform a read-modify-write operation on a port register shortly before having changed a output pin. Let's take the really obvious case of ORing 0 into the PORT register. OR is a read-modify-write operation. The OR instruction will read the existing register value, perform the OR, then write the result back to the register. Now imagine the previous instruction wrote a new value to a output pin, but that pin hasn't had time to get to its new state yet. The read part of the OR instruction reads the current PORT register value, which is not the most recent value written to it because the pin hasn't slewed to its new state. The OR with 0 doesn't change anything, so the old state of the PORT register is written back to it, essentially cancelling the previous write.
Now you may say that ORing 0 into a PORT register is silly. In most cases that's true, but that was just to make a obvious example. Consider that the BSF and BCF (bit set and bit clear) instructions actually perform a read-modify-write on the whole port register. Consider the instruction sequence:
bsf portb, 1
bsf portb, 2
Let's assume all port B pins are set to outputs and are all low to start with. After the first instruction RB1 will start going high. Due to capacitive loading, RB1 is still low and PORTB therefore reads 0 when fetched as part of the second instruction. Bit 2 is now set, so the value 4 is written to PORTB. RB1 will now go low again since 0 was written to that bit. RB2 will start going high. The net result of this instruction sequence could be that only RB2 is high, not RB1 and RB2 as probably intended.
The LAT register was introduced to avoid this problem. It holds the last written value, not the actual instantaneous pins state. If this instruction sequence was performed on LATB instead of PORTB, both RB1 and RB2 would be driven high at the end regardless of how slowly they might get there.
So what do you do? On a PIC 18 and higher read from PORT and write to LAT, and there'll be no problems. On the other PICs, avoid any read-modify-write operation on PORT until you know all pin states have settled. Some people will tell you to always use a shadow copy, modify that, then write that to the PORT register. That's just silly voodoo programming, of course. You know your circuit. Most of the time a single NOP between a write and any read-modify-write is all that's needed. If the pin can't get to its new state in at least one whole instruction cycle, then the circuit should most likely be fixed anyway. In rare cases shadow register can be useful, but those are rare cases indeed. Mostly they are just a waste of cycles, RAM, and one more thing to mess up, especially for the kind of people that blindly follow rules like "always use a shadow register". A much simpler answer is that those kind of people should just stick to a PIC 18 or higher.
I am a TI employee who works in an MCU development group, but this is not an official statement from TI. In particular, this is not an official statement about roadmaps or priorities. Also, I'm not in marketing, so if I contradict any of our marketing material, they're right and I'm wrong. :-)
M D's answer is correct, but I thought some more detail would be helpful. TI targets different applications with different requirements. When you're competing for an MCU socket (and there is a lot of competition in this industry), both features and price matter. A ten cent cost difference can win or lose the socket. One of the main drivers of cost is die size -- how much stuff is on the chip. Thus, it makes sense to have different product lines, and different families within those product lines. Product lines differ mainly in peripheral types and architecture, while families within a line products differ mainly in terms of cost and feature set.
Here are some details on the product lines:
As you can see, these product lines are targeting very different applications with very different requirements. Putting a 300 MHz Hercules chip into a battery-powered device would be a disaster, but so would putting an MSP430 into an airbag. Physical size can also matter. A 337-pin BGA package is awkward to fit in a tiny sensor, but it's nothing for a piece of industrial equipment.
Within the product lines, there are multiple families. C2000 Delfino devices are faster, have more peripherals, and have more pins on their packages. They can also cost (at least) twice as much as a Piccolo device. Which one do you need? It depends on your application. MSP430 has some products that balance power consumption and performance, and others that focus solely on low power. (That one-battery MCU maxes out at 4 MHz and 2 kB of RAM.)
There are many products within each family because new products are developed all the time. Transistors get smaller/cheaper, so more stuff can go on a chip. A mid-range MCU today would have been ultra-high-end ten years ago. Each product is usually made to target a few specific applications and support others where possible.
Finally, there are multiple variants of each product (AKA the last digit in the part number). These usually have different amounts of memory and (maybe) small variations in what peripherals are available. Again, this is all about providing a price range.
The short version is that each product provides a different balance of price, performance, and features. It's plain old market segmentation. Our customers are manufacturers, who care much more about small price differences than end users. People buy every part number we have, so clearly the demand is out there. :-)
UPDATE: Jeremy asked how the requirements of big customers affect the design process, and whether we make custom MCUs. I've seen several TMS470/570 MCUs that were made for a single large automotive customer. That group also had a couple MCUs whose architectures were designed by and for one customer. In at least one of those, the customer wrote most of the RTL. Those are under heavy NDA restrictions, so I can't give details.
General market products usually have at least one big customer in mind. Sometimes big customers get a special part number. Sometimes we'll add a peripheral just to win a big socket. But in general, I think big customers are more of a floor than a ceiling when it comes to features.
An extreme example of custom parts is our high-reliability group. I've only heard stories about these guys, but apparently they take existing products and remake them to work in extreme conditions -- high temperatures, radiation, people shooting at you, etc. I know someone who buys HiRel TMS470s for down-hole drilling, where the temperature can reach 200C. (Maybe this one -- in stock at Arrow for only $400/chip!) They have a bunch of standard products listed on the web site, but from what I've heard, they can build to order even in small quantities -- you can buy a dozen HiRel versions of any chip you want if you're willing to spend $50,000+ per chip. :-)
As a rule of thumb, everything in business is negotiable if you're spending enough money.