Breakpoints, yes. But many folks (myself included) set the breakpoints in the debugger itself--you don't have to put that line into your code to set a breakpoint.
Since some folks write JS that has to go through a "build" process, it's easier to set a breakpoint in the debugger than to go back, modify the code, and "re-build" to get a breakpoint.
It would be even easier if you could just fix the build system.
If you are worried to modify your code because of the long build process then the build system probably needs rethinking - make sure that only the files that were modified are rebuilt, configure your text editor so that it runs build script on file save.
It's not that it's long, it's that it has to be done at all. Even without a build process (or one like ours that takes at most 5-10 seconds) it still takes longer than finding the line of code you're concerned about and setting a breakpoint within the debugger itself.
To each there own as to how setting breakpoints works best for them in their workflow--my only reason for commenting was to let people know there were other ways to set breakpoints than adding "debugger" lines all over their code.
Another reason to use breakpoints in the debugger itself, when doing client-side development, is that you usually don't need to refresh the page (well, you may have to, if the breakpoint is in a piece of code that executes only on page load). You set the breakpoint, trigger the action that executes that code (or call it from the console) and you're already debugging :)
Since some folks write JS that has to go through a "build" process, it's easier to set a breakpoint in the debugger than to go back, modify the code, and "re-build" to get a breakpoint.