Ideally, you'd have the same configuration in development as you do in production. That way, you can have a higher probability that if it's slow in dev, it will be slow in prod, and if it's fast in dev, it will be fast in prod. I'm guessing that this would be a pretty significant drop from what you have in production. But given that few places have the budget to have dev match prod, I understand dealing with what you have.
With 10 instances, the part I'd be concerned about is the RAM. Figuring that somewhere around 4-6 GB should be held back for the OS, any other software on that server (A/V, etc.), and an emergency buffer, this means you have about 26-28 GB of RAM for 10 instances, or under 3 per instance. I don't know what you're averaging now, but it's probably a good bit more.
As such, I'd try to max out that server's RAM and set the maximum memory per instance equal to what it is in production. Even though there won't be many people using the server, skimping on RAM will give you false negatives with performance and will make it harder for developers to get accurate performance tests.
Unless you have dozens of developers constantly going at the databases, you'll probably find CPU to be adequate (though not really good). The low disk speed is a bit concerning, but get enough RAM and the disk speed shouldn't be too big of an issue for a development server. Again, you'll likely find additional performance-related problems in dev that you won't in prod (if you have more CPUs per server and faster disks and more spindles available per server), but when you're on a budget, those are the trade-offs you have to make sometimes.
I would be totally remiss if I didn't point out Glenn Berry's book on the topic.