Never met a single engineer who didn't want faster build/test cycles.
If I’m a professional driver, but my passenger likes being discreet for example, then maybe I drive a Camry instead of a Rolls Royce. In your case, you probably don’t need a professional-grade laptop.
Me however, also a professional programmer, I run about 10 docker containers, a big ide, and lots of other hungry programs. I definitely am less limited when my computer is faster.
Programmers have to deal with compilation wait times, lack of RAM slowing down workflows, network latency, etc. We have to wait for the computer to do their job.
I await the day that I won't have to deal with this and computers would be as fast as our train of thought(human input latency nonwithstanding). But I won't hold my breath.
You can be a professional, without being a professional user of all your tools. In fact, for any such tool, there's probably only one or two professions that are professional users of that tool specifically (i.e. where that is the tool that constrains their productivity.)
Many professions aren't constrained by any tools, but rather are constrained by human thinking speed, or human mental capacity for conceptual complexity. These people aren't "professional users" of any tools. They're just regular users of those tools.
So, to sum up — when a tool is described as being "for professionals", what that means is that the tool serves the needs of people who are members of a profession whose productivity is constrained by the quality of that tool. It doesn't mean that it's for anyone who has a profession. Just people who have those professions. They know who they are. They're the people who were frustrated by the tool they have now, and for whom seeing the new tool elicits a joy of the release of that frustration. An "ah, finally, I can get on with my work without [tool] getting in my way so much."
-----
Programming is a profession that is most of the time constrained by thinking speed. (Although, some of the time, we're constrained by grokking speed, which is affected by the quality of the tools known as programming languages, and sometimes the tools known as IDE code-navigation.)
Very little time in a programmer's life is spent waiting for a build to happen, with literally no other productive tasks that they could be doing while they wait.
(Someone whose role comes down solely to QA testing, on the other hand, tends to be a professional user of CI build servers. Faster CI server? More productive QA.)
Obviously it depends greatly on what kind of software you are writing, but at all my dev jobs, I eventually end up waiting for some amount of time while the CPU heats the room up.
Notably, VIM is inevitably more gentle on my CPU than VSCode and similar.