I've found that it has to do a whole lot with 2 things... the first is how the idea is presented and the second is the perceived ROI.

On the first subject, asking "Why do you do it this way, when this way is faster, less time...?" is taken by many (whether right or wrong) as a either a full frontal assault on their talent if they wrote it or a really stupid question if they didn't. A question of this nature is pretty much out of line even in "grownup" shops where people have pretty thick skins. Questions of this nature are frequently dismissed from new folks as "here's the new guy/gal that thinks they're smarter than everyone else" even if they are. I was hired into my current job to make such improvements as "faster, less time" but, even with everyone knowing that, you just can't ask the question quite that way. In fact, such questions should actually never be asked because the answer is so obvious... "They didn't know any better at the time they wrote the code".

Don't get my wrong. I hate the attitude of "because we've always done it that way" or "we've never done it that way before" but that's mostly due to a simple lack of knowledge possibly spawned by a lack of motivation to get smarter. It's become a "safe" attitude for a lot of shops. And that's the key. It's difficult to motivate someone by hitting their egos and "tired/true" methods with a bat. You have to respect their "metal" or you aren't going to be of much help at all even if you're a freakin' genius.

Rather than asking questions that have such a high potential of alienating you (which renders you useless, for the most part, and will certainly increase the "great divide" between Developers and DBAs), do it in a mentor-like fashion making sure that you're a friendly, helpful mentor instead of an (perceived to be and perception is reality to many) arrogant pulpit thumper. Instead of belittling someone by asking them "Why do you do it that way when this way is much faster, less time...", ask them "Can I show you a little trick that I think you'll like?" If they say "yes", turn it into a thoughtful teaching session (be a mentor). If they say "no, I don't have the time" or just plain "no", respect the metal and leave it alone for that moment. Instead, do the same as if you were going to do the mentoring thing. Improve the code, measure the performance/resource usage/ease of maintenance of both methods, and then bring it back to them when their hair actually isn't on fire.

Notice also that I didn't say you have to take any crap from anyone. Crap will happen just because it's the nature of the beast because there's a conflict between current methods and the "right" methods. People will make ad hominem attacks even if you haven't. Be prepared to disarm such arguments with good code and a mentor-like attitude. Don't be equally as arrogant.

There's another hurdle to overcome and that's ROI. Some companies have the idea that performance doesn't actually matter especially when it comes to overnight jobs. For example, it might not matter to a boss if a particular job takes 6 minutes or 6 hours so long as the job finishes be 8 in the morning. They just don't understand that the server could be doing other equally important things during those 6 hours or that you may not have to buy additional hardware/licenses to get the job done as the system scales. Even though I'm a bona fide speed freak that likes to see everything be optimized, I can let things like that go (for now) because it's usually not the only fish in the pond and you have to remember that regression testing and fallout from such changes is expensive. Will that 6 hour code become a problem in the future as scalability grows? Absolutely but (and unfortunately) ROI is sometimes based on "urgency". Some people actually believe that if it's not an "urgent" problem, there's no ROI in "fixing" something that isn't broken (yet) and it can take quite a while to change that perception. All performance problems are based on ignorance, IMHO, whether it's based on "bad" code or simply using the wrong tool. It takes "training" to overcome that and you have to be the incredibly patient trainer to make a real difference.

The bottom line is that change for the better frequently comes slow because of the very attitude you mention and the sensitivities of the human element. You absolutely have to remember that you can't always make the right point up front. Sometimes you have to "Give people the opportunity to fail" (notice I didn't say "Make them fail") before you can show them a better way. The other thing that you have to remember is that "A person forced against their will, is of the same opinion still". Not all "new ideas" are "good ideas" and even Microsoft(almost all companies... I don't mean to pick on just MS) has proven that in virtually ever piece of software they've ever published. Especially as a new person, you have to understand that many Managers, DBAs, and Lead Developers have been badly bitten by "new ideas". You need to help them lead rather than push them into a corner.

Drop the bat... stop thinking about frustration... respect the metal... become a mentor. Although it won't seem like it at first, you'll make a much bigger impact and in much less time.