Necessary? No. Any piece of functionality could be implemented with or without classes. Many languages don't have the concept at all, including one of the four I work with regularly.
Do I use them? Absolutely. OOP is a very powerful tool for abstraction and encapsulation.
Faster or slower? None of the above. The use or lack of use of OOP won't have a performance impact. For that matter, in many cases speed is a non-factor; typically my #1 concern about code is not how fast it is, but how maintainable it is. By far the largest and most significant cost of a project, in both dollars and time, is maintenance. I want code that is easy to read, easy to write, easy to test, and easy to modify with a minimum of ripple effects on the whole rest of the code base. OOP can assist with each. Speed is critical at certain times and places, but even there, whatever minor overhead you might have with virtual function tables and the like is almost certainly infinitesimally small. Typically where I care about performance, it's network time or database time that vastly dominate the latency, not CPU time.
Easier or more tedious? I work on a large product (somewhere in the ~20 million SLOC range) and as mentioned work on both languages that have the concept of an object and those that do not. I definitely prefer reading, writing, and working with objects - it makes it a lot more convenient to encapsulate functionality and provide abstractions. It makes work far easier in general to use it.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
Oh, and as to being confusing: that really just indicates you don't intuitively understand the concept yet. It can be confusing at first to learn to think in object-oriented terms, but once you can, it's very fast and easy.
That will be the same with many concepts you'll come across in software. At first the ideas seem new and alien, and it's a struggle just to understand them. After a while, you develop some confidence, things go quicker, and as you keep on keeping on, eventually you develop mastery, and can quickly and easily think about problems in the right way. Pointers are one of the first conceptual hurdles most of us come across. Class-based OOP is another. There are plenty more to come - if you're not regularly having that experience, you're probably not developing your skillset as much as you really could.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
Another good thing about OOP and classes is software reuse. If you write good, clear and
concise code, other people can use your classes without having to write their own.
Plus any modifications they make to it (as long as your credited with the original), can
even help you learn more about your own code. It's sort of a win - win
Double Helix STL