For me it is exactly the other way around. I hated those weekly 3hr status meetings. Sometimes, I fell asleep. And I hated that all the specifications had to be upfront, without flexibility for the team or the stakeholder. Nothing was more counterproductive than implementing a solution, that when I knew half-way in that it was flawed.
With Scrum, if something bugs me, I bring it up. We do standups only if required (put a signal on the board). Meetings have a single goal and having it as a ritual (culture) helps to accept it. My team is not always the exact amount of people. People get sick or have holidays or just migrate into other teams. If my team needs a specialist for something, we bring someone on board for the required time. But we also try to share knowledge and not to specialize, because that would be a risk (sickness, holidays, termination etc). We also learned to break down requirements into stories that are small enough, so we can reason about it. We understand Scrum as a foundation that we can agree on. And if we disagree, we figure out how to change the boundaries of Scrum so we can move on.
Well, if my math is correct, 15 minute meeting every day still beats 3hr status meeting every week. Our status meeting was only about 0.5-1hr long, and we actually got a bit more done, because you're not supposed to go into detail during the standup.
Anyway, what you seem to praise is Agile (as per the manifesto), not SCRUM, and I agree (although some problems are actually suitable for upfront specification). Still, distractions can be a problem on the other extreme that needs to be managed too.
That assumes a 15 minute meeting only steals 15 minutes from your day. It's usually closer to an hour once you factor in the work-free buffer zones surrounding it. (Cf http://www.paulgraham.com/makersschedule.html)
With Scrum, if something bugs me, I bring it up. We do standups only if required (put a signal on the board). Meetings have a single goal and having it as a ritual (culture) helps to accept it. My team is not always the exact amount of people. People get sick or have holidays or just migrate into other teams. If my team needs a specialist for something, we bring someone on board for the required time. But we also try to share knowledge and not to specialize, because that would be a risk (sickness, holidays, termination etc). We also learned to break down requirements into stories that are small enough, so we can reason about it. We understand Scrum as a foundation that we can agree on. And if we disagree, we figure out how to change the boundaries of Scrum so we can move on.