I've had a look at a few ways of achieving this within the current iTerm2.
Richard's suggestion of less works well — the argument -S turns off wrapping within less and allows you to use the left/right cursor keys to move to data that is off screen. By default, moving over to content to the side in less is performed in quite large jumps. This can be controlled using the # parameter. You can set the environment variable LESS="-S # 10" such that LESS doesn't wrap by default and jumps left/right in blocks of 10 chars. Works pretty well.
There is also a tool "most" (available on Homebrew) for which non-wrapping of content is the default and left/right scrolling character-by-character. That seemed perfect for when you do need to process long lines in this manner; however I tried using it a little and found it wasn't really as polished as less. e.g. I intended to pipe some grep output into most but forgot the input filename to grep - the terminal was frozen awaiting input from stdin that would never come. I couldn't break out of this so had to close that tab and loosing that shell. Repeating this with less, Ctrl-C allowed me to break out and correct my stupidity within the same shell. It turned out that I didn't have read rights to the file to be grepped and when piping through "most" I just saw an empty file; whereas with less it showed the error message by presenting stderr instead. All in all, less seems to be the far better pager.
Neither of the above seem to allow horizontal control by the trackpad as mentioned in the Google Groups discussion.
To get trackpad control seems to be a bit of a faff. I found that using tmux (again in Homebrew) and issuing the command Ctrl-B ":resize-window -x 1000" would present a really wide terminal to programs within the session; causing them effectively not to wrap. With the iTerm settings "Allow two finger swipe between tabs" disabled (in Advanced) and "Enable mouse reporting" enabled (within the Profile->Terminal config) - I could kind of use the trackpad to scroll around. But, similar to less's defaults, the move was in big jumps and it didn't feel reliable at all. Too annoying to use in my opinion.
I'd just keep to "less -S". ;-)
One issue I did find was that my personal default less environment variable is LESS="-Xr" - the X instructs less not to clear the content on exit and the "r" allows raw control chars to be displayed (which helps when viewing output from Terraform). My use of -r caused -S not to work, but using -R (a softened version of -r) did not cause this issue. So, in my case LESS="-XRS #10" seems to be the best environment variable for this long-line behaviour.
I feel it is worth mentioning another "less" feature of which I wasn't aware for the longest time - when viewing a file using less; entering F (i.e. shift-f) instructs less to move to the bottom of the file and follow updates to a file as one would normally do with "tail -f". I could well imagine this could be a useful parameter in this use case if the data is coming in live...