The main reason I started handicapping myself with the single monitor was so that I could write software without the need of my desk/office. I found that when I was working at my desk, I'd need a break at set intervals to get 'unstuck'. While decompressing, I'd often start thinking about whatever problem I was solving and I'd run back down to work on it, all the while wishing I wasn't in my office.
So I started thinking about all of the reasons why I didn't use my laptop screen. The main ones were (1) I couldn't see as much code on my screen at the same time which made both 'holding the amount of code needed to understand the problem' and 'navigating code to the correct block I was studying' more difficult and (2) when debugging, it was convenient to have the debugger display on one screen and the application on the other. The first was a mostly solvable problem and I ended up solving it by writing a Visual Studio extension that highlighted common code points that I was often looking for (constructors and factory methods). The second was becoming less and less of a concern because I had begun taking unit testing very seriously and this resulted in a desire to 'write a test for it' over 'debug the code to see what went wrong'.
Now that I've been doing that for three years, I will never go back. When I was working at home (which I did for a decade), I would just move rooms when I felt 'stuck', allowing me to get a change of scenery, a brief break, and get right back on working without feeling like I need to be 'out of my office'. I can even pack up the laptop and head to a cafe if I feel the need, without feeling like I'm handicapped by the single screen. But the more surprising thing for me was that my coding practices improved. When I feel like I'm having a hard time 'keeping all of that code in short-term memory', I immediately see the lack of multiple monitors as a symptom of the problem with the root cause being 'my code is probably not written ideally'. I refactor for that. But most of the time I end up writing it correctly the first time because I can't put it all up on various monitors to refer to while writing an unnecessarily complex implementation.
This directly feeds into the second problem: I find that I very rarely use the capabilities of the debugger. My code is easy to unit test, so I write tests every time for very nearly everything. When I encounter a failure, the design of the application lends itself to identifying the troublesome point and I can write a test to verify the problem (and later, verify the fix).