I wish he wouldn't keep pushing "perf" as an example of why putting things in the kernel is good.
After years of development perf is still missing features the perfmon2 "pfmon" utility had 5 years ago, although it has gradually been catching up.
perf didn't succeed because it was in the kernel, in fact I think that was a barrier for many people trying to develop it. perf really took off once it was included in a package by the distros, in combination with perf_event kernel support (which meant interested users didn't have to hand-patch their kernels for counter support anymore).
As someone who has spent a lot of time working on perf-related tools that aren't in the kernel it's a bit insulting to read this linux-kernel thread where all our efforts are made out to be pointless until perf came along. Especially since things like perf's possibly-soon-to-arrive named event support is going to use event tables taken from the (still developed) libpfm4 project. (Yes, the perf developers refuse to link to the libpfm4 library to get these event names, but somehow it is a good idea to strip the laboriously gathered event tables out of libpfm4, fork them, and include them in perf in a slightly different format, see: http://article.gmane.org/gmane.linux.kernel/1431566 ).
I think perf would be much better off as a separate project, it would definitely make my life as a performance counter developer easier.