As systems grow you always end up wanting to parameterize GET apis with things that you can't reasonably continue to stuff into headers, matrix params, and a wonky URL (in my experience).
Which is why we need to get rid of the WebDAV baggage around the SEARCH method [0] and establish a general-purpose, safe/idempotent HTTP method that accepts a message body to supply parameters rather than using URL query strings; a draft RFC for such a method exists. [1]
We have fifteen years worth of client and proxy implementations that do not support GET with a request body. This ill-conceived spec change violates "be conservative in what you send" just to avoid adding a new idempotent request method that actually defines usable semantics for its body.
If I had to consume an API with entity-body-having GETs, I would definitely conclude the designers had no practical experience in the field, and had read about this obscure possibility somewhere...
in this case there is no reason to do that and you lose all possibilities of using cache if that is desirable
GET /users/@me/accounts/:id --> specific user account
GET /users/@me/accounts --> all user accounts
would suffice and would read naturally , it would also give you ability for other user with appropriate credentials (admin kind) to see some other user account information
yes, very disappointed with design decisions (I understand that from a purist perspective URI is opaque but well named URIs help communication with people)
My point is that in complex systems 'get' use cases come up that don't fit well in urls.
Suppose you have too many accounts to list, so you start taking predicates in the API, or you start returning a pagination token that's passed back in on a subsequent requests. You quickly overwhelm URIs and have to start serializing complex objects in headers or query params. Eventually you give up and switch to POST so you can just post a json body and be done with it.
I do build a complex systems and pagination payload always have links to prev/next etc. , POST for GET would kill all client side and server side caching we leverage and would make system really hard to scale. We still didn't run into compelling case to use POST for this type of fixed queries.
What you are talking is ad hoc search capability and that is usually done differently either by posting content type which indicates search payload or using different generic URI for search queries within a whole system