Well, it depends. Say you want to model a user of your application, this looks very much like a candidate for an object. Sure when you just start, you can use a dict or even only the id, and have functions working on it.
But will this scale when the number of possible actions over a user will be in the hundreds? Then, with all it drawbacks, the object model may make sense: at least, you have a way to know which actions are available on a given thing.
When you have a "user" in hands, how do you know what you can do with it? When it is an object, it is relatively easy, as the methods are bundled in the object. If you use a functional paradigm, you'll have to resort to some other mean, maybe you'll regroup user-related functions in a place (but some are mixed), or check for function accepting user_id as an argument, but these means seem less straightforward to me.
Ah, so you're talking about tooling. Specifically, the way object method invocation lends itself well to autocompletion or intellisense?
In functional languages we tend to use far more generic facilities than this. Some examples of this are lenses and scrap-your-boilerplate style generic programming.
We also tend to think differently. We don't "hold a user in our hands" and ask what we can do with it. We think in terms of extending our base language until we can express the solution to our problem in a trivial way.
That's all good but my personal experience about complexity and big code bases sadly don't include functional paradigm.
Note that I'm not taking about complex problem with potentially simple solutions, I'm talking about inherently complex systems, like, say, the HR system of General motors.
