Let me start by making one clear distinction. We can have objects at two levels.
- Objects can be stored in the database as either columns in a regular table (object-relational) or as object tables.
- Objects can be used in PL/SQL, even if the the underlying tables are purely relational.
Although there is nothing fundamentally wrong with using objects in tables, they can cause problems if 3rd part tools (applications and reporting tools) do not understand them. Even though the object-relational technology in Oracle is very mature, I avoid it at the table level, except for those types provided natively by Oracle (XMLTYPE, OrdImage, OrdVideo etc). Indexing of object data can also be a problem unless you build your own custom indexing cartridges.
With that stated, I believe you are talking about the second option. Using object types in PL/SQL only.
The use of objects in PL/SQL is purely a preference thing. They don't out-perform procedural PL/SQL. They are not necessarily clearer or easier to use. Where they do benefit is when they are being used by client developers who are used to object-orientated programming, because they seem more familiar than regular procedure calls.
Objects often allow you to describe real-life things more naturally than relational tables. For example, lets look at a person. We can create a "Person" object that has all the information relevant to a person in a single object. This data may come from multiple tables (employee, communication_devices, addresses, departments etc.), but as the person object we can present in a single, real-world-like form. That is the advantage.
So why do your company want them? It sounds like they want to be able to pull back objects containing all the relevant data/methods and cache it, so they can repeatedly reference it without going back to the database. From a data perspective this is no different than a record structure to hold the data, but exposing the methods within the type may prevent them from having to hit the database for each method call, so they may benefit.
In reality, the only way to be sure is to do a proof of concept and test it. If it works better then great. If is sucks, you've all learnt a very valuable lesson for the next time it comes up in conversation.