Default trace vs auditing in SQL Server Currently I am working in an environment that has the default trace enabled and I would like to propose that we add SQL server auditing to our environment.
I'm looking for some points to put forward to our more senior database members and to management who think that the default trace is enough.

What is the difference between these two different solutions?
Is there any advantages/disadvantages of using one over the other?
Default trace is just a collection of behavioral information about the system. It's not the same as auditing. They do different things and support different purposes. One doesn't supplant the other.
Further, default trace is actually inferior to another thing running on all systems by default, the system_health Extended Events session. In terms of information gathered and load on the system, system_health is a better alternative to the default trace. The information there is all about errors, deadlocks, long wait times, long running queries, stuff like that. It's not about security and change auditing.
SQL Server Audit is using Extended Events under the covers as a mechanism for tracking security, change auditing, and the rest of stuff that's needed for auditing your servers. That's distinct from the default trace or system_health.
So, I'd take it to your more senior people that, you probably need both. The good news is, system_health is already there. Now, implementing auditing carries with it quite a bit of work and some changes in how you do deployments and other things. You'll want quite a bit of testing before you implement it.