A web service call means that the routine has to be declared as static, and as such then the page class instance is NOT created, does not exist, and thus any web method call can't touch/use/see any controls on the page, since the web page is still sitting on the user's desktop client side. Kind of the whole point of using a web method call (to avoid a post-back). Without a post-back, then the controls and their values are still sitting on the user’s desktop, and they not been posted back to the server, and thus you can't see or use or touch any of the controls in code behind for a web method call.
That means the web method has to return values to the client side, and then your ajax web call has to update the controls. You can't change controls on the user's desktop with server side (code behind) unless you post-back the page for the server to see those values.
So, when you post-back, a WHOLE new instance of that page class is created, the controls are loaded, and then code behind runs and can change value(s) of controls on that page. When all of your code is done running, then a whole new copy of the web page is sent back to the browser, and on server side, all that code, the variables and everything is disposed, tossed out, and now does not exist. (the web server is now ready to accept any web page from any user -- not just you!!!).
So, the server does not keep nor hold a copy of each web page for each user in code behind. That page class ONLY exists when a post-back occurs.
But a web method does not post back the whole page, and hence it must be "static" method (no instance of the page class exists). So, if your static method calls some routine on that page? Well, it not the same class instance as when a post-back occurs. Without page post-back, then controls in code behind will be null and void -- just like they are in any web method.
I have a feeling you don't grasp how the page life cycle works here, and without that knowledge, then attempting to write code will seem like voodoo.
So, it works like this:

Note how your page class - code behind is NOT in memory on the server.
YOU DO NOT have this:

Note very carefully here - the web page is on the CLIENT computer - it is NOT existing at all on the web server side.
And you DO NOT EVEN have this:

So, when you click on a button, or do a post-back, then you get this:

our web page is sent up to the server. You now have this:

So NOW your page is sitting on the server.
NOW an instance of the page class is created, and your code behind starts running.
Your code behind can modify controls (even whether they are visible or not), but the page is NOT interacting with the user - ONLY code can MODIFY the web page. So, one change, or MANY changes to the web page can occur, but AS YOU update things like a text box etc., the user does NOT see these changes just yet. So, you can't say run a loop to flash a text box on and off - since the changes are occurring on the server - the client-side browser does not have the web page any more!
It is THEN sent back to the client side, and the server-side class instance and code is TOSSED OUT - does not exist. Your server-side page class is disposed - removed from memory, and the web page code behind does NOT exist any more.
So, page travels back to the client side, is re-displayed, JavaScript is loaded, and THEN JavaScript starts running.

So, if you call a web method, then you have no post-back, and the controls and values in the browser are still sitting on the user’s desktop. You can't then with a web method call attempt to update controls, since they are on the desktop of the user! A web server can't reach out to yours or my browser copy and start changing it.
So, if you want a web method call to update some controls on the user's web page?
Then the web method has to return some values, and the client-side JavaScript code can then change or modify the controls on the web page.
Or, you dump use of a web method, suffer a post back and the above so called "round trip" and while the short time the browser page is up on the server, then your code behind can make changes to the web page before that WHOLE web page is sent back to the client side for viewing in their browser.
Remember, the web server is serving everyone, not just you the one user! So, code behind and the variables go out of scope after the page is rendered. You can very much think of this like calling some subroutine or function. After that function exits/returns, then all of the variables and values in that routine are now gone, disposed and out of scope.
A web page is much the same - the page class and variables ONLY exist during that short time that a copy of the browser page is up on the server, and during that time, the user see's the browser "wait" spinner.
So, study the above diagrams, they should help you grasp why when calling a web method, such methods can't change controls on the browser, since no copy of the browser was sent to the server, and hence controls don't exist server side at that point in time.
So, there are two simple solutions:
First, let asp.net webform automatic wire up a ajax page for you. That can be done by dropping a script manager onto the page, and then using what is called a update panel.
A update panel means you can dispense with using a ajax call, and you don't need a web method, and you see that you can continue to use 100% server-side code - including code that can modify controls - but ONLY controls inside of that update panel.
So, the markup will look like this:
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
<asp:Panel ID="EndPanel" runat="server" CssClass="container" Visible="false">
<asp:Image ID="Border" runat="server" ImageUrl="assets/ui/border.png" />
<div class="overlay">
<asp:Label ID="Victory" runat="server"></asp:Label>
<br />
<br />
<asp:Image ID="Skull" runat="server" ImageUrl="assets/ui/skull.png" Width="32px" Height="32px" />
<asp:Label ID="DeathCounter" runat="server"></asp:Label>
<br />
<br />
<asp:Image ID="Star" runat="server" ImageUrl="assets/ui/fullStar.png" Width="32px" Height="32px" />
<asp:Label ID="StarCounter" runat="server"></asp:Label>
<br />
<br />
<asp:Label ID="TimeElapsed" runat="server"></asp:Label>
<br />
<br />
<asp:Button ID="Finish" runat="server" Text="FINISH" OnClick="Finish_Click" />
</div>
</asp:Panel>
</ContentTemplate>
</asp:UpdatePanel>
So, place the content you want to "ajax" inside of the content template, and that includes the button and it's click event.
Now, your button click code in above can run, you don't need any web methods, and you not see nor suffer a full-page post back. Keep in mind that this is what we call a "partial" page post back.
That means the page on-load event will run first, and then your code button (like any button click does). So, that means you need some caution in what you do in the page load event, and in most cases, you place the page load code inside of a if !isPostBack code stub.
However, note close how you not see the browser "spinner/wait" icon, and note how the page scroll position etc. does not change. So, using an update panel is a great way to ajax part of the browser page, and you not suffer a full page post-back (round trip).
And what is nice is the button click code can thus modify controls inside of the update panel. And you find that you can in most cases even grab values that are not inside of the update panel, but you can't modify them (since they are a not part of the "small chunk" of the page you are posting back (the update panel part only gets posted back to the server).
Give an update panel a try, they are great for your type of use case, and even better is then you don't need to adopt any JavaScript web method calls as you have.
The second approach is to return back from the web method the several values that you want updated on the page, and thus you write the code client side to update the controls when the web method returns such values.