OO is not bad. You can write bad code in any number of different ways. Whether or not you choose to write OO code depends on how you like the style, how your teammates like the style and what you are doing. If you want to be a good programmer, you should learn how to write modular imperative code, OO code, FP code and declarative code. It takes a long time and a lot of learning to be a good programmer.
As for what should start with, it doesn't matter in the least. Start with whatever you feel like, or whatever your friends are doing, or whatever is convenient for you. Keep an open mind and have the attitude, "Well, I'm going to do it all sometime so I don't need what I'm doing now to be the 'best'". Don't try to save time -- you can't do it, because there is no end point in learning that you can achieve in your lifetime. Just progress down the paths that interest you and try to enjoy yourself.
Focus on delivering solutions using what you know best. If OOP is doing the job for you, by all means stick to it. Code is a means to an end. In fact, these days, if I can be able to deliver a software solution to my clients without writing a single line of code, I will go for it.
In OOP those groups are called classes, and the fun is that you can instantiate them and call them objects. And within those objects you can set a state, so those functions operate against it. A nice feat of OOP is that you can also inherit logic and expand it.
Btw. no, this is not how OOP works. With the method I outlayed I have very easy time to achieve idempotency, the thing you suggested makes it harder because the objects have internal state and the method calls can depend on those.
In the wrong hands, it does. Easy to tangle OOP. But the point is each of the two paradigms has its own benefits, and should be used when best for the task at hand.
The key to understanding classes, IMHO is that you are grouping functionality to make the code more cohesive. The style of grouping is to group the functions based on the program state where these functions make sense.
Often people go the other way around and write entity relation diagrams. They write classes to encode the data that they want to work with and put the functions that interact with the data into those classes. This actually leads to code that isn't OO (again IMHO). It actually more closely resembles modular programming. You have areas where you say, "I'm dealing with that data here". All of your instance variables are essentially global to that module. Especially when the classes become large, this becomes mostly indistinguishable from imperative code with global variables.
Instead, consider the parameters that the methods on your class use. Imagine that you had no instance variables and that you had to pass all of the parameters to your functions. Now group all of the functions that use mostly the same parameters. That's a class. The instance variables represent some state of the program and the methods work on that state. Afterwards you can make diagrams to see how these objects interact with each other, but it usually doesn't make sense to do it before hand (because otherwise you end up with bags of data and functions that act on that data as if they were global variables).
Or, more concisely: An class is not a table in a DB and you shouldn't model it the same way ;-)
Indeed. Sometimes tho one just needs to pass a data set to a function, then the result the another, and so on, without the execution branches needed for figuring out the modularity rules and constraints of OOP. And that is where functional programming is relevant (and in math like scenarios, where speed and accuracy are key). But not as a rule of thumb, for everything programming.
As for what should start with, it doesn't matter in the least. Start with whatever you feel like, or whatever your friends are doing, or whatever is convenient for you. Keep an open mind and have the attitude, "Well, I'm going to do it all sometime so I don't need what I'm doing now to be the 'best'". Don't try to save time -- you can't do it, because there is no end point in learning that you can achieve in your lifetime. Just progress down the paths that interest you and try to enjoy yourself.