Python should be more than sufficient. My GUI uses python and can get 35datapoints/second (1500Bps) with usb serial or about 15dp/second (600Bps) with LoRa. I can probably squeeze more, but the least of my problems is the python GUI. The only thing that doesn't seem to keep up is pyqt refreshing widgets, and that's an intermitten issue that I think is because I'm not using pyqt correctly.
I'm using pglive for my active plotting and have several threads, but only two are used for the plotting: the main GUI thread, and a thread dedicated to reading input from serial and handing it to the GUI. The threading divides the work so that you see less lag per loop from it processing. If your widgets are responsive, but you're still getting slow data input, you might want to slim down what you have going on per loop. If you're familiar with multithreading (which is super easy in python, just don't forget to put locks around data that gets handled by multiple threads), divide up the tasks, and that should show some improvement.
Another thing: how are you formatting transmitted data? If it's in plaintext, JSON, XML, CVS, or any plain text format, it's going to be incredibly slow. You need to use the byte data the numbers are stored as and ctypes in python to decode it. My data is 40bytes big, and that stores a "magic identifier" (prevents interference from other LoRa devices), runtime, altitude, internal temperature, magnometer (3 integers), accelerometer (3 integers), and the rest is a bit map for statuses/booleans (for example, when my relay is active, it will be indicated in the bit map). The same data in JSON format (a web optimized format), it would probably be in the order of 150bytes, give or take, which would seriously reduce the amount of data I would get because that's almost 4 times bigger, and it has to be parsed. Byte data can be mem copied and then the ctypes struct already has an understand of how the data is formatted so there is WAY less work to do per datapoint.
(My GUI: )