The number of fast breakpoints is limited by the target. The Tiva™ TM4C123GH6PM microcontroller which is used on your board supports up to 8 hardware breakpoints.
If you set more than those, you end up with software breakpoints which work differently. There are different approaches, especially when executing from flash. A common approach is to insert a trap instruction, some architectures offer special breakpoint instructions for example the ARMv7-M has the
Breakpoint causes a DebugMonitor exception or a debug halt to occur depending on the configuration of the debug
<imm8> Specifies an 8-bit value that is stored in the instruction. This value is ignored by the ARM hardware,
but can be used by a debugger to store additional information about the breakpoint.
Now inserting these instructions in code which runs inside the RAM is easy, but for code executing from flash, you have to reprogram the sector where you set the breakpoint. This is what the J-Link unit supports, other like Lauterbach debuggers as well. These have the added benefit, that they can be set in external flash as well (if supported by the debugger), which isn't always supported by hardware breakpoints. The breakpoint instruction will cause an exception, which is then caught by the debugger.
A different approach which is much slower is that the debugger switches to automatic single stepping and compares at each step if a breakpoint has been reached. This slows down the execution quite dramatically and the speed is limited by the JTAG/SWD clock, the slower the debug clock the slower your execution will be.
If you hit these limitations your debugging process will always slow down, but how hard depends on the debugger used. Some rely purely on software, so it gets even slower. Others will implement the software breakpoints in the debugging front-end hardware, so that it doesn't need to ask the PC all the time.
Transferring large arrays is mainly a function of the debug clock, but if your debug speed exceeds the PC to debugger interface, a debugging probe with internal buffers will help. It can read the array into the buffer at high speed and stream it to the PC at lower speed.
With that being said, I guess most on-board debugging probes are very limited in their capability. So they're likely to act as a relay for the PC which implements all the debugging protocol in the driver. A full-fledged debugger will implement the protocol in the firmware and use the available bandwidth to the PC more efficiently. So I'd say that a "real" debugger will likely increase the speed of the debugging process and make it a more pleasant experience.
I'm working with a Lauterbach debugger and it's so powerful and flexible that I'm only scratching at the surface of the capabilities.