What really is the essence of POJOs/models or domain-driven objects in the situation in context considering business requirements changes?

I was told this chunk of code is a really nasty anti-pattern.

  @SuppressWarnings("unchecked")
  private static Map<String, Object> getArgs(Object obj) {
    return new HashMap<>((Map<String, Object>) obj);
  }

  public void buildAndUpdateCustomer(List<Object> list) {
    for (Object obj : list) {
      Map<String, Object> args = getArgs(obj);
      daoProvider.updateCustomerName(args);
      daoProvider.updateAgingMia(args);
    }
  }

  public void buildAndUpdateTax(List<Object> list) {
    for (Object obj : list) {
      Map<String, Object> args = getArgs(obj);
      daoProvider.updateTaxAmount(args);
    }
  }

  public void buildAndUpdateLedgerBal(List<Object> list) {
    for (Object obj : list) {
      Map<String, Object> args = getArgs(obj);
      daoProvider.updateLedgerBalance(args);
    }
  }

An argument for that is because:

It removes all of the type safety the compiler provides and even removes the name checking.
Contains unnecessary casts (Map<String,Object>) obj
Difficulty understanding what a method does by its signature because method parameters are of Object type. List<Object> list

My List<Object> list could be a list of invoice tax amounts, list of customers, list of ledger balances et cetera...which could be rewritten like this.

public void buildAndUpdateCustomer(List<Customer> list) {...}
public void buildAndUpdateTax(List<Tax> list) {..}
public void buildAndUpdateLedgerBal(List<Ledger> list) {..}

This means having to create Customer,Tax and Ledger POJO/entity/domain objects for each method. I have got over 100 buildAndUpdate() of these sort of methods updating and doing different things, do i have to create 100 of these POJO/entity/domain objects?? Maybe this is bad practice but i feel like having to add classes all over the place bloats the entire code base and kills maintainability.

Solution

You basically ask why not use Map<String, Object> instead of domain objects.

I can't imagine too many things which are worse for maintainability than Map<String, Object>. Heara are just a few reasons:

As a developer you'll have no idea which fields are allowed or are mandatory, and which types do they have - unless you dig through the source code.
As for digging through the source code, since it's just Map<String, Object> it's hard to know where this pseudo-class is actually used. Unlike "find references" of a normal class.
You domain objects may have additional utility methods, for instance providing easier access for data.
You can't enforce rules in Map<String, Object>. Basically, you can create a instance which is invalid from the business logic point of view.
Refactoring. Imagine you'd need to rename a field. Good luck finding all those places this field may be accessed.

So, yes, I'd definitely create a 100 domain objects.