Consider the relational database. Queries to it return vectors of maps of (eventually) primitives. Databases as varied as Mongo and Redis do the same.
Consider communication to a Javascript or native app front end. It is via (JSON or XML) vectors and maps of (eventually) primitives.
The same applies in the reverse direction: maps and vectors come from the front end, are munged, and are inserted as maps and vectors of (eventually) primitives.
Are all apps 3-tier web apps? No. But I would claim they are the dominant kind of app today, in terms of mindshare and sheer amount of effort devoted to easing their development.
So, interesting: an enormous amount of effort is spent on apps that convert map/vector-structured data into map/vector-structured data.
On the way from one map/vector structure to another, is there an advantage to converting the input into objects - packages of state and behavior? Sometimes, yes. Most of the time? I'm really doubting it.
However, because of the mindshare dominance of object-oriented programming that came because of Java - "Smalltalk for the masses" - it's hard for most people to think of an approach other than a pipeline of structured data -> objects -> structured data. The tools and frameworks and languages push you toward that. So: a programming model tailored to objects with serious lifetimes has been used for data that lasts only for one HTTP request.
The peak of Smalltalk's popularity roughly coincided with the peak of Lisp's. Either could have been a way forward. Lisp's popularity died in the "AI Winter". Smalltalk hit it big (in a weakened form) with Java - and with C++ and Ruby and C# and ...
I propose that life could have been better. Suppose Lisp (and successor languages organized around flows of data through a pipeline) had gotten the mindshare that, in our world, Smalltalk did. And suppose the OO style had been one widely ignored but kept alive by a small group of enthusiasts (as Lisp was). In such a world, maybe - just maybe - the dominant app style today would have been supported by languages and frameworks better suited to it.
And in this world, we'd have had - at some point - the OO true believers building new possibilities (languages, etc.) on top of VMs originally written for functional languages. We'd have seen a resurgence of that mostly-forgotten OO style for use in problems that really benefit from state+behavior.
That is: we'd end up with both OO and functional programming, because both are the bee's knees, but the order of serious investigation and development would have been better tuned to what the world ended up demanding from computers: data slurped, transformed, and delivered.
Caveat: Smalltalk-80 really nailed the OO style. The Lisps of that era did not, in my opinion, nail the functional style. I programmed in Common Lisp in 83-84. If I remember right, higher-order functions, even simple things like mapping a function over a sequence, were not idiomatic. So Smalltalk -> Java -> Ruby required much less invention than MacLisp -> ? -> Clojure would have [1].
[1] I am leaving out what I understand was a rather bitter split [2] between the Lisp thread of languages and the statically-typed functional languages (that led to Haskell and F#). That's because I think that the notion of HashMap<String,String> is fundamentally broken. That is, runtime typing of the values of key-value pairs, and liberal acceptance of extra keys, is super-convenient on the edges of an app. Figuring out how to accommodate that in statically-typed languages that build off of Pascal records would have been an unproductive diversion.
[2] I haven't come near to systematically interviewing the participants, but I know enough to suspect that the history of the "Lisp and Functional Programming" conferences would make a great case study of cussed human nature leading to a huge missed opportunity. Almost as bad as whatever it is that makes vim users fail to recognize the obvious superiority of the Emacs approach [3].
[3] That's a, I say, that's a joke, son. Jeez.