One of my pet peeves is flash for the sake of flash. Shredder guitar players that aren't using flurries of notes to achieve a musical end are performing the musical equivalent of competitive eating. Writers who use a ten dollar word where a dime-a-dozen word accomplishes the same goal are just insecure and trying to sound smart. And using rich media on a site just because you can is a complete waste of our time.
I recently went through this struggle at the office. The team handling the change-management for a minor release of some Sharepoint functionality decided that they wanted the CEO and Chief Architect talking about the release. From the beginning, I was skeptical of the value of doing so. In response, they just cut me out of the email chain. One day, one of the members of the team came to my cube and said that the CEO was ready to shoot his video. I told him that I didn't agree with it and that they should talk to another department and borrow their equipment to shoot the video. When I asked, "why are you doing this, anyway?" the response was, "We want to put a YouTube-style video on the intranet." That's not a why. That's a how.
The situation came to a head last week when they were pressing the internal communications person about including references to the video in the CEO's blog - there was a good deal of "push back." I tried to get to the bottom of it by asking, "What is the purpose of the video? Is it marketing? Is it training? What do you hope the viewer will do after seeing the video?" My best understanding of their responses was that it was a marketing endeavor. Since the goal of marketing is reach, I suggested that the blog really was the channel with the widest reach. Unfortunately, they hadn't explained it to the CEO that way and so the CEO was against using it in that manner. The real problem is, that the whole effort was conceived to give credit to the team which is why their answers to "why" didn't match.
Here's my advice: Whatever you're doing (strategy, implementation, design, deployment, etc.), always ask what the benefit to the user is. More importantly, ask what you hope the user will do or how you think their world will be different after interacting with your system (media, application, org changes, etc.) and let the answers to that question define how you will implement the solution. In the end, the only opinions that matter are those of the people who give your solution value, the people who are affected as a result of your solution. Make sure to advocate for them and you stand a better chance of doing the right thing.