First you're violating the encapsulation principle. Each "Form" is a "black box" - you create a form, tell it to show itself, and let it worry about how it'll do it. If you want to interact with the form, you send "messages" to it. So for instance, if you want to change the text in a TextBox on a form from outside the form, you would have a method called "SetText()" which sets the underlying text property. You don't just expose the text box.

You method is great for small applications. If I was writing a little hacky program, I'd even prefer it. That's why you can do it in VB6. But in the case of large software it can be very difficult to maintain.

I can't think of a single case where your method would result in a better designed application than doing it the correct, object oriented, way. To rely on such a method would be proof that your design needs work.

>> Object orientation, if not working the way that comes natural to people, is stupid

Well, it's actually a lot more natural. Lets say you are a form. I am also a form. Your brain and way of thinking is "private", that is I can't simply make you change your mind directly. I can influence you by saying things that might make you reconsider your poor ideas about not using OO in C#, which might (hopefully) change your mind indirectly, but I can't just change your mind for you. Likewise, as a Form, I shouldn't be able to update a DataGrid you have displayed. I could however, ask you to update it, and let you handle how the grid should be updated.

If you want to expose the text in a TextBox, expose public properties:
Code:
  public class Form1
  {   
     .....
     public string Username
     {
         get { return usernameTextBox.Text; }
         set { usernameTextBox.Text = value; }
     }
  }
Now, lets say you use this method. Everywhere you might want to change the displayed "username" in a text box, you could set the Username property on the form. Lets say you're doing it from 3 different places. You then change usernameTextBox so that it's a dropdown box. You'll change the name of it to usernameDropDown. But oh no, you're calling that field from 3 different places, and seting the value in a text box is much different to setting it in a dropdown, so thats 3 places you're going to copy that code.

Contrast that to using the property getters and setters. In my method, you're simply saying "set the username to PaulS". You don't give a flying hoola hoop about what setting that name is actually going to change. In the properties setter on Form1, you would put the code to set the dropdown. You've just reduced code, made it easier to maintain, and you're not going to get laughed at when you reveal the code to anyone.

So while the OOP way might seem harder (creating the public properties for everything you want to set) it's actually a lot better and makes it a thousand times easier to maintain when you change the underlying controls on the form. Each form is a seperate object, and only it should be able to change it's internals.