I would suspect the real reason is something along the lines of "We download the entire contact list in JS in the client to do autocompletion, so if it gets too big your browser runs out of memory and crashes." They might also be storing the contacts database as a single row in their backend store. Either way it's not necessarily as easy as a quick change in an upper limit, and the number of users affected is likely to be quite small, so I wouldn't be surprised if this wasn't exactly at the top of their priorities.
$10 says that the support guy has no idea why it's not easy (or whether it's easy), which is why he gave a completely generic non-answer. And even if it isn't a top priority, the support guy should definitely put it into the system as a feature request, ideally with a link to the issue so the customer knows it was entered. This might as well have been an automated email:
Dear <customer>,
Unfortunately, we don't allow <feature requested>. If you'd like to see us do <feature requested> in the future, please follow these instructions to request it...
I'd presume you're right about the support guy not having all the knowledge required for my hypothetical answer, but if it's not a live communication (i.e. chat or phone), why not spend the time calling up someone who would know?
Because support people deal with spurious and unimportant issues like this all the time. They need to deal with them quickly so they can help people who have real problems.
Imagine the number of people who try to test the limits of Google's software. I'm sure they get thousands of issues every day with people who have intentionally tried to hit the limits on size of inbox, number of emails, length of search term, etc.
Actually, no. This is exactly Google politely telling him that the particular request is a low priority. Unless you FR meshes with an existing roadmap item OR it is causing a significantly large business impact for an Apps Premier customer OR it is novel & potentially profitable and they humor you, it's not going to happen. Scalability is important at the scale of 200 million users, and going after the edge cases doesn't make good business sense.
That said, they do take FRs seriously, and they are incredibly (astonishingly) open about their roadmaps... depending who you are.
Equally though - it's far from an unforeseeable problem, this individual is unlikely to be the first affected and they've had the data to see this coming for some time, and it wouldn't be impossible to fall over to a separate, more scalable system, for the larger user databases such as this.
