The concept of triggering a build using a Subversion (or other scm) commit hook is a good one, but from a build plan maintenance standpoint it's not realistic to update the svn commit hook every time a build plan is added, removed, or has its keys changed. So the triggering implementation documented here isn't workable, so we rely on polling and the checkout process is much less efficient than it could be.
At my company, editing the commit hook requires working with operations; adding/editing a build plan is something an engineer can do.
It seems the proper way to create a build trigger would be to have the post-commit hook call Bamboo on every commit (or potentially some subset of all commits - that can be scripted). Then Bamboo does a quick check (using svn log) and maps the paths of all the modified files to the build plans in Bamboo using each file's svn path. This creates a candidate list of build plans to trigger as a result of the commit. Of the candidate list, only the build plans that are set to "trigger build when scm changes" would be triggered.