What is current consensus on client libraries? Braintree for example requires that you use their client libraries where as Stripe makes them optional. With Google's gRPC thing I can definitely understand using libraries for performance. Otherwise, isn't making simple REST calls without custom libraries sufficient for most uses? Or if you want a library, something generic like Unirest [1]?
I've used the simpler GCP APIs (like the Machine Learning ones) with direct REST calls. I've also been forced to use the REST API for things like Google Sheets because the client library documentation was so confusing.
For more complicated services, using a client library makes sense. Why reinvent the wheel?
With gRPC/Swagger/OpenAPI/etc you can also generate your own client stubs if you need to.
IMO, if you require a client library, there better be a really good reason...
(I work at Google Cloud, and often work with the API/libraries team. Opinions are my own)
If your REST API is documented in OpenAPI/Swagger spec, then you can use Swagger Codegen [1] to generate API clients (Java, C#, PHP, etc), server stubs (e.g. C# NancyFx, PHP Lumen, Python Flask, etc) and API documentations.
Client libraries can be helpful and sometimes reduce a lot of plumbing/boilerplate that you would end up writing on your own (eg: authentication, paging).
Most environments -- Ruby, Python, PHP -- have minimal HTTP clients in standard libraries however they all have capable third-party libraries. Unirest as you mention, but also Requests for Python or Guzzle for PHP.
Product-specific clients generally build on these third-party libraries or go with the standard libraries instead. The product-specific clients generally offer more comprehensive error handling, for example if an API relies on arcane error codes that wouldn't immediately be obvious to an end-user.
1. http://unirest.io/