Anyone who has written software with any complexity knows the importance of logging clearly readable error messages to make debugging easier. Cryptic or short error messages like "Error #5" won't work.
Part of an astromech's job is troubleshooting, which can often involve reporting errors or issues to a mechanic, which often could be a living being. Astromech droids, at least the R2 models, can parse at least some spoken languages, since R2-D2's comments are displayed to Luke so he can read them on the screen in his X-wing. Astromech droids already have a speaker they can beep through, so providing speech for them would be trivial.
I looked through the Wookiepedia, but didn't find anything in the R2 or astromech articles about why they don't have speech abilities. While the article on astromechs covers the topic of communication, it never explains why they can't speak.
I know when Star Wars was written and released, it was well before any practical speech synthesis systems were available, but almost everything in the Star Wars universe has been either retconned or rationalized.
Is there ever any in-universe reason given for why R2-D2 or other astromech droids cannot speak?
Let me clarify a couple points, since, even though I included some of this previously it was misunderstood. (I didn't think I'd have to spell it all out specifically -- sorry about that.)
- Astromech droids can understand language (presumably, or at least, Galactic Basic Standard) spoken to them.
- Astromech droids (at least R2-D2) can respond by using language, as shown in The Empire Strikes Back, when R2-D2's comments are displayed on a cockpit screen for Luke.
- The previous two points show that astromechs (at least R2 units) have full language processing abilities, both to understand and to make themselves understood.
- Astromech droids can make sounds, as has been demonstrated so often.
So all that is needed for astromech droids to speek is a table of phonemes so it can match the words it wants to use with the phonemes to play back. Compared to all the AI software required for a computer to process and respond in any language, and the database for all the words in that language, this requires a very tiny amount of memory.
Therefore the cost of onboard speech for a droid or computer that can already process language is very small, since 99.5% of the software and hardware is already included.
Now for the troubleshooting aspect. If you've never had to do any software or hardware debugging with systems that can provide error messages (and, after retiring from my own software business, I've done a lot of that), there are a few points to know:
- Spaceships can be forced down or crash on planets without technology (can you say, "Dagobah?"), so it is entirely possible a pilot (and crew) could die if proper debugging tools are not available after the craft has been damaged.
- Depending on a third piece of software, such as a protocol droid, could be a fatal error, since one may not be available in many situations that are certainly well within the range of expected and likely possibility.
- Depending on computer systems that are part of the damaged spacecraft one is trying to troubleshoot (such as a cockpit display screen for interaction) when that isn't necessary can also be a fatal error since that system can be damaged.
- When you're debugging or troubleshooting, relying on a display screen instead of simple verbal responses can be difficult at best. (Picture having to work on an engine of an x-wing and needing to continually climb into and out of the cockpit to read a screen while you're calibrating something!)
In other words, the "going around my thumb to get to my elbow" approach of forcing a downed pilot, or one on a not-so-up-to-date planet, to have a protocol droid or to use display screens on the ship one is trying to fix could lead to depending on damaged equipment that could make repairs impossible. This could easily be avoided by providing speech on astromech droids.
Sorry for all the extra blather, but I get the feeling people are ignoring these important points that are part of the problem.