This is less of a definitive answer than a musing about some seemingly underlying assumptions within the question. For the question itself Supercat has already given a near perfect answer. While it is of the typical kind where everyone know it's wrong, it does tick all boxes. I seriously would love to give it double points :)
Different Computer Classes
The most obvious issue with the question may be that it separates different 'classes' of computers - and more important implies important advancements made by them in prior. While it is true, that mainframes implemented many solutions first, they where still tied to their repertoire of tools - like command line operation on terminals in next to all cases. And even within the mainframe world solutions weren't developed for the fun of it, but when needed. Much like with minis and micros in parallel or later.
For example the AID facility of BS2000 (a /370ish OS) did already support quite complex interactive debugging in the early 80s. But all based on very cryptic command line arguments.
Need for more comfortable (I would prefer that term over 'advanced, which is more of a marketing blurb) debuggers grew out for one of more capable systems and more complex software, but more important due changes in software development. This includes especially the need to dive into large chunks of code generated by less then well known tools (compilers), imported from libraries or worst of all, inherited form prior developers.
This development happened independent of machine type or 'class'.
Source Level Debugging
Already early microcomputer systems offered basic debuggers that did go past all hex handling of Hex-Kits. For example the original Apple II Monitor included convenient single-stepping and breakpoints with disassembling the instructions. And with the introduction of disk drives and Assemblers many additional tools came to hand, including source level debuggers. That's the 1978..1980 time frame. Eventually with the ORCA system as a first plateau supporting very convenient Assembly as well as Pascal and C - noteworthy here, that is wasn't until the mid 1980s that C became a professional supported choice on Apple II (or similar) systems.
In general it was not only missing need, but more so missing capabilities of the systems in use that prevented the use of more comfortable features. To access join binary and source code the later needed to be at least indexed, a feature the quite limited memory of these systems could, if at all, only support for extreme small programs. Even more so if the source code had to be displayed. Impossible without multiple disk drives.
Beside Assembly (and the all omnipotent BASIC) PASCAL was the only other choice. Here the UCSD system was eventually the best known - and it made a great case how to provide high level support on small machines. The p-code did include many references to the source/module structure already by default, and due its module structure parts of the system could be swapped in on demand.
It wasn't until affordable machines by default had a RAM size of 512 KiB or more and hard drives that more comfortable features as requests became possible for most programming environments.
Workstations are Anything But PCs
When comparing machines, that have been sold as 'workstations' at their time, with other available it becomes clear, that there is no basic difference to other machines of the same time -- except they usually represent an upper end configuration.
A Sinclair QL of 1984 used a 7.5 MHz 68008 with 128 KiB RAM and micro-drives, while a SUN 2/50 of the same year had a 10 MHz 68010 with 8 MiB RAM and (at least) one HD. The same point can be made for any other computer sold as Workstation - not to mention todays Gamer PCs that outclass what many manufacturers sell as workstation :)
Home Computers are Computers at Home
While this sounds nice at first, it's a classic post-hoc fallacy. After all, that would make any computer someone may have at home a "home computer". Of course including any mainframe, mini or workstation running zOS or Unix. It's obvious this won't work as a portable classification - most definitely as porting the same computer into an office would right away turn it into an office computer - wouldn't it?
The location a computer is set up can not retroactive define a class.
The question contains a lot on unnecessary constrictions and implied assumptions that are neither clear nor helpful at all, and at the same time an unclear definition what environment exactly is asked for.
It may be useful to drop these restrictions and clarify what kind of functions and their representation is asked for.