... no two jobs required the same batch files and manually editing those files was error prone. So, I created a Tk GUI to automate this process.

Just a terminological nit-pick: a GUI does not automate a process -- if it is well-designed, it optimizes the interactive part of the process, so the user's task is reduced to the fewest, easiest, most intelligible inputs and decisions, making efficient use of human abilities in a job that would be too hard to "automate".

As you approach the rewrite, examine the user's experience with the current tool: Are there parts of the task that seem unnecessarily repetitive or redundant? Are there parts that involve irregular changes among distinct sub-tasks (as opposed to having similar sub-tasks grouped together)? What parts are still error-prone for the user, and what sorts of validation/sanity-check are provided to locate and correct likely errors (automatically or on demand)?

The point of this would be to start coding a new version from "first principles": what does the user really need to do here, and what would be the simplest, most effective way to enable that?

In a zealous swing, I extended this tool to also execute that batch file on the hardware and parse the resulting output. As of right now, the program is over 2000 lines of code.

Think of the output parsing as a separate process. You can tie it to the "batch-prep" step as tightly or loosely as you like, but write it as a separate piece of code. If it involves knowledge that is also used in "batch-prep", then that shared knowledge is the basis for your new modules -- you need to write the code to encapsulate that knowledge just once, to objectify it. (The "run-batch" step can be the last part of the "prep" or the first part of the "output parse" -- or both, if both the prep and the parse have distinct controls that might motivate a fresh run to test a different set of choices.)

It is a GUI tool with added threads, socketted communication, and intra-tool communication links (bound tags) dynamically activated based on results, using plenty of global variables. Given this mess, can you recommend some reading...

Could some of this complexity have arisen from the "exploratory" or "toy-project" nature of the initial development? This might be another reason to re-examine the user's perspective and re-formulate your "first principles"; if it's a basic "configure -> run -> assess" sort of task, perhaps you don't need threads, or perhaps the inter-/intra-process communications can be reduced to a simple pipeline model. If you're not using a relational database, would it help to use one (in case it makes the program simpler to code and/or simpler to use)?

Anyway, I don't think I'd recommend reading as much as writing... How long would it take to describe the relevant facts about the batch file format and the output of the batch process? How would you document the range of controls and inputs that the user needs to handle when prepping the batch file? How hard would it be to scope out and describe what the user needs to do with the output? If you write that up first, and derive clear data structures to capture it all, then organizing and writing the actual code will seem to follow naturally from that.