Wrappers are a great idea if you need a small set of what the library provides. Also very valuable if the library you are using doesn’t have good support for testing.
Certainly you should not wrap a library “just because”. The benefit of doing so should be easy to articulate.
A potential counter point here is that wrappers help reducing churn if the library being wrapped is actively developed - this can apply to both external libraries and ones developed by other internal teams. A wrapper limits the surface area that needs updating and can make some otherwise quite painful upgrades easier, at the cost of maintaining the wrapper itself. As ever, it’s a situational thing of course!
The best assumption to start with is that adapters are bad by default, because they are an unnecessary layer to maintain (and potentially a point of failure and bottleneck depending on what they are and do). Then, make the argument for the adapter as a guilty until proven innocent case.
If you can make a solid case for it, fine. There are many solid cases for adapters, e.g. drivers for a database or hardware.
Never write an adapter that you can handle more scalably, flexibly, and almost as easily by calling something directly.