How can I properly avoid the 200 local variable limit?

(Note that using non-local variables in a do end block doesn't help anything. Also, in terms of performance, local variables are slightly faster than non-local variables, and not using a table is slightly faster than using one - but the difference is very small; it's best to consider performance when working on a piece of code that (for instance) runs in a loop every frame.)

For the sake of organization, it is better to separate your script into smaller segments (ideally smaller scripts) that are each responsible for a smaller job (see https://en.wikipedia.org/wiki/Separation_of_concerns). If you can make each segment "know" as little as possible about other segments (and ideally knows about as few segments as possible), you decrease the number of dependencies for each segment. That way, if you later decide to change something, you minimize the amount of other code that you'll need to update.

To fix your problem, you could put all your variables into tables, but on its own this doesn't improve organization/separation of concerns and is also incurs a performance penalty (and a fair bit of rewriting).

Ways to help fix your problem that also help with organization:

1. Keep it all in the same script, but divide up the parts of the script using do end and local variables. The idea is to make sure that a variable is only in scope for a section of the script - define any functions that need to use it, then end the block. The goal is to have each section of a script only deal with one main idea. If you are successful, you may find that you can move some of the blocks into different scripts entirely (although this may not be easy to do if there are a lot of variables that are accessible to the entire original that the block relies on).
2. Improve organization even more by using ModuleScripts to store useful functionality (assigning the functions and any other values to the ModuleScript's table so that other scripts can access them, of course). If you can identify a job that your main script is doing, you may also be able to put that in its own LocalScript -- ex, maybe one of the jobs is to make buttons light up when you hover over them. If it needs to access variables from your original script, you could store those variables in a ModuleScript - perhaps your original script could become a ModuleScript that returns a table of useful variables, for instance. Alternatively, see if you can pass in information to functions rather than functions accessing the information themselves (ex, instead of a piece of code knowing to light up a specific button, turn it into a function that is told which button to light up).

Method 1, managing locals with scopes, is probably the least work and it should solve your immediate problem, though you should consider transitioning into the 2nd option over time, even if you don't want to do it all at once.

An example of method 1:

local Players = game.Players -- variable accessible to all blocks
local someGlobalVar = thatManyBlocksUse

do -- Manage a specific aspect of the GUI, ex some buttons
    local button1 = pathToButton1
    local someLabel = etc
    -- use button1/someLabel/etc
end

do -- Manage a different aspect of the GUI
    -- more local variables
    -- etc
end

-- You can also "export" functionality from a scope by defining the variable outside the 'do end':
local CountSpeciallyNamedChildren -- arbitrary piece of functionality
do
    local specialNames = {SpecialName=true, VerySpecialName=true}
    function CountSpeciallyNamedChildren(obj)
        local ch = obj:GetChildren()
        local count = 0
        for i = 1, #ch do
            if specialNames[ch[i].Name] then
                count = count + 1
            end
        end
        return count
    end
end
-- You can now access CountSpeciallyNamedChildren but specialNames is hidden and therefore doesn't count towards the variable limit. It's also clear to see where "specialNames" is used/modified, making it easier to find bugs.