What arguments can a developer make to management that he could be Product Owner for his Scrum team?

Okay, wow... let me start this with an explanation. Your "Scrum Team" has not been doing Scrum for 2 years. Management has not seen fit to enable it to do Scrum for the last 2 years. I will answer your question as asked, assuming you were doing Scrum, but I have no crystal ball to tell you how much is applicable to your situation. The only information I have is what you don't do. That is proper Scrum. It is hard to cook something tasty based only on the information what the person doesn't like. So take this with a grain of salt, again, I will answer the question as asked:

What arguments can a developer make to management that he could be Product Owner for his Scrum team?

A product owner is a decision maker for the product. Experience as a developer or Scrum Master is a nice little bonus on the side, but largely irrelevant for a Product Owner.

What you need to point out is that you can be a product owner. That you can make decisions for the product based on business needs. That you can organize and integrate the stakeholders, probably other business people in your company, to make this decisions based on their input. And that you can transport this decisions to the developers in a way they can work on it.

None of the above requires even one hour of Scrum Master or Development experience. Focussing on your experience in these areas is not going to help, it is only going to waste time and effort that could be spent on making you shine.

With 20 years experience, you probably know the product. You know the customers. You maybe even know the stakeholders. That is what makes a good Product Owner. That is what you should focus on, your experience with the business side. Because Product Owner is a business job.

On why there should be a product owner at all, compared to your current two people setup: The Scrum Guide says the Product Owner is a single person. Not a comittee. It is one person whose job it is to make those decisions. They can come to their decision however they want, but it needs to be one person. Unlike Scrum Master or Developer, this makes the Product Owner the one person in the team that really has a 40h job. The Scrum Masters job gets easier the better the team gets, the Product Owners job doesn't. If the team gets better there is ever more need of good Product Backlog Items to work on.

So the Scrum Guide says it should be one person accountable, experience says it is a full-time job, not a side hustle for people that actually have other jobs. One good angle would be focussing on the fact that the current two people have their own jobs and are great at their own jobs, but Product Owner is a job in it's own right and needs to be filled, so that those two people can focus on their area of expertise. Preferably filled by you. That might come across better than criticising the current setup and indirectly the people running it.

Again, a word of caution: this is the logic rationale by the book Scrum version. Very likely you are not running Scrum by the book, so to be honest, it probably matters more to be friendly with your manager. That is just the reality. Call it networking, brown-nosing, vitamin-c ("c" for connections"), but there is a good chance that a good, logical argument for your position will get you 10% there and a good standing with your boss is the other 90% regardless of your arguments being good or not. Welcome to the real world.

former scrummaster and a developer

and

What arguments can I make to management to let them take a chance on me (a senior software engineer in the same role for the last 10 years with 20 years of development experience) to let me do PO work in addition to my regular development?

Those are exactly the arguments. Tell them that you want to evolve, and being a PO is something that you want to pursue.

If they seem reluctant, then you can propose to undergo a test period, when you act as a PO, under the monitoring of some designated team members. Just make sure that the target of the test period is specified in clear measurable terms.