None of it seems particularly specific to Linux. It's widely accepted that front line support is going to be absolutely appalling. In general, they employ complete fuckwits because they're cheap. Not only can they not help you with Linux problems, but they often can't even help with anything competently.
Here's some recent examples of non-Linux-related technical support. First from Yahoo! Groups -- I was kicked off one of their groups because my mail servers apparently rejected a few messages. I assumed it was due to SpamAssassin, but clicked on the helpful link which purported to give the actual error which "my ISP's" mail servers had given. It said:
550 Most messages without it are spam, so your mail has been rejected.
I happen to know that's bollocks. My servers wouldn't say that. In fact the rejection message will have been two lines, and said:
550-RFC2822 says you SHOULD have a Message-ID. 550 Most messages without it are spam, so your mail has been rejected.
So I filled in their support form, reported the above and said that their system should report the whole message instead of just the final line. And I also suggested that if they aren't going to reject RFC2822-ignorant messages lacking a Message-Id: header then they should at least add a Message-Id: of their own before resending the message to their subscribers.
The response seemed to completely miss the point...
We have checked your Yahoo! Groups account "firstname.lastname@example.org" and it appears to be in full working order. Our servers are running normally at this time, so you should not be experiencing any problems.
Your Yahoo! Groups account was labeled "Bouncing" because your Internet Service Provider (ISP) returned messages sent to your account as undeliverable. These are called "bounced messages". Accounts are automatically labeled "Bouncing" after three consecutive days of undeliverable mail.
Creative Labs did almost as well, too. She Who Must Be Obeyed bought a Muvo² MP3 player. I filled in a support form asking if there is a firmware upgrade with Ogg support, and if not, when one will be available. In the case that there were no plans to support Ogg, I asked for the reasons why this was the case. The form required ancillary information, including the operating system which was being used. Obviously I selected 'Linux'.
The response to the question "can the Muvo² play Ogg files?" was "I'm sorry, but we don;t[sic] support muvo in Linux.". I know I said non-Linux-related examples, but IMHO that doesn't count as a Linux-related support question, because the actual question I asked had nothing to do with Linux.
I responded, asking precisely why the operating system was relevant and asking for a more coherent answer to my questions. The answer came back "I'm sorry, but any of our mp3 players support OGG.".
That's a good thing, right? If any of their mp3 players can support ogg, then that means ours does. But still they didn't tell me how. I suspect they meant to say that none of their mp3 players support ogg, but in that case they failed to answer the questions about future support.
Then of course there's the idiot in my employer's IS department who responded to a report that the VPN link from the Cambridge office was losing all packets above 1408 bytes with a comment that it wouldn't matter if I were using the correct SMTP smarthost. But that wasn't frontline support -- scarily, that was actually someone who was expected to have some clue; but I've come to the conclusion that a large part of his behaviour can be attributed to a deliberate attempt to be obstructive.
It does cut both ways sometimes, though. I was in a retail outlet a while ago and bought three items, including a toner cartridge. The monkey managed to scan only two of them, and I didn't get charged for the toner. Normally I'm quite an honest person, and I would have pointed it out -- but in a place like that I consider it perfectly reasonable not to. They employ monkeys who can't help their customers, to whom they have a duty of care. So I consider their loss to be entirely their own responsibility.