Basically, an aspx page is implemented as two classes. One of these classes contains your code behind code (.aspx.vb) (and, depending on which version/model of ASP.Net you're using, also some designer generated code (.aspx.designer.vb)).
The second class is created when the page is first requested (or the site is pre-compiled) and contains any inline code from the .aspx page and other code generated by ASP.Net, and includes e.g. code for any controls declared with runat="server".
This second class inherits from the first.
So, if the first class takes responsibility for hooking up its event handlers, it uses a Handles clause*:
Private Sub ABC(...) Handles Button1.Click
Button1 belongs to this class because it was put there by the designer generated code. Everything is local to this class, and so the method can be Private.
If the second class takes responsibility for hooking up an event handler, it does it by using attributes on server controls, such as here:
<asp:Button OnClick="ABC" Runat="server"
Now, unless ABC is a method declared inline inside the .aspx file, it has to be from to the first class (or any class from which the first itself inherits from)
We now have a situation where code in the second class wants to refer to code in the first class. And so, the rules of .NET say that the member that it's trying to access cannot be Private.
What you shouldn't have, as you have in your question, is both classes taking responsibility for hooking up the (same) event handlers.
*It doesn't have to use a Handles clause - it could also set up the event handler using AddHandler inside e.g. the Page_Load event, or anywhere else that's appropriate. Handles is idiomatic for static controls on a page in VB. In C#, there's no equivalent to Handles, so the event handlers are hooked up with C#'s equivalent of AddHandler, +=.