If you think back to why OO was invented, you'll see that you don't need OOP at all, but sometimes it makes your life a lot easier.
Back in the days of C coding, a very large program could become quite messy and difficult to keep working with. So they invented ways of splitting it up into modular chunks. OOP takes this approach and makes it even more modular, putting data with those chunks of program logic so they are even more separated from the rest of the code.
This allows you to write bigger and bigger programs, safe that you've changed your huge elephant of a task into a hundred mice-sized tasks instead. The added bonus is that you can take some of these 'mice' and reuse them in other programs!
Of course, the real world is not quite like that, and object reuse never quite caught on in the way it was intended, but it doesn't mean it's a useless paradigm.
What is useless is an over-reliance on either style of coding. Anyone who does OO with a thousand tiny, insignificant classes is not really doing it right - they're making a maintenance nightmare for themselves (or someone else). Anyone writing a procedural application that is only 3 functions is also making life hard. The best way is the middlle ground, large-ish objects (sometimes called components which is where we looked to be going once upon a time) that can provide a fair amount of stand-alone code and data that is much more likely to be reused in isolation from the rest of your app.
My advice for next time: try writing your usual procedural code, but create a single object of your main data structure. See how you find that working with it is easier than passing data around from function to function.