Let me share my thoughts as former maintainer of this project:

The underlying API client (MethodsClient) can throw any of these, and the current implementation provides getters to access them. So, it's not because of the breaking change, these data structure should not be eliminated. I hear that having three types here could be unnecessary for most cases, but this could be still beneficial for other users.

If your concern is the lack of easy-to-use getMessage() method, the internal code could be changed just to override getMessage() to return the underlying exception's message string data. Only one of these three usually exists, so checking the existence of them one by one within overridden getMessage() method should work for the purpose.

This could be a minor breaking change, so ideally it should be considered in the next major version. But in practice, having such a change with sufficient notice in release notes should be okay too.