The worst thing about book-style scrum are four hours long sprint planning meeting. I never met a developer who would enjoy quarreling for half a day about estimates even if the planning is gamified through application of planning poker. Planning twenty or more stories in a row is not only strenuous, but also very frustrating for programmers who are supposed to commit to their estimates without having access to their favorite search engine or an option to do some technical experiments. At Agile Slovenia 2013, Vasco Duarte presented a modification of scrum which discards estimation of individual stories and assumes each story to require one day of work. Such modification makes a lot of sense since the preferred size of stories in scrum is half a day to two days anyway. At the sprint planning meeting the main task is therefore just prioritization of stories which puts the product owner in the driving seat and forces the discussion away from implementation details and towards rationale for doing the individual stories.
While appealing, I consider Vasco's proposal as too conservative and that we shouldn't even do implicit estimation hidden in a requirement to break features into one day long stories. The fundamental reasons why we cling on estimates are to catch deadlines and to track people productivity. I think there are better ways to achieve these goals that don't frustrate programmers by requiring them to do explicit estimates.