Thrift provides a high performance (can be 1-2 orders of magnitude faster than REST) functional API mechanism that supports the widest array of languages and platforms in its class.
When most folks say "web service" they are implying something with a REST or HTTP/JSON type API. These API types are the gold standard over the Internet, effectively leveraging the infrastructure of the world wide web and all of the intermediate devices and technologies it consists of (proxies, reverse proxies, gateways, etc.).
Backend systems don't often have all of the infrastructure of the www, however. Also backend system are frequently decomposed into microservices these days, meaning many services need to collaborate to perform a task. Reducing backend latency and wire payload can make a big difference in user experience. Another value prop is that Thrift is function based. If you are decomposing a monolithic application into services, it will probably be easy to extract bits into services with function interfaces. REST/HTTP interfaces use routes, verbs, query params and various other bits, all alien to an old school modular monolith. So in a microservice world, fast services that are organized into functional interfaces can pay big dividends.
Containers and platforms like Kubernetes make tooling like Apache Thrift and gRPC (a similar offering from Google) make a lot of sense. In fact all of the hyperscale folks use something other than REST on the backend for performance (Facebook invented Thrift, Google has ProtoBuf and stubby, Twitter created Scrooge and Finagle [originally built on top of Thrift], etc.).
One last point is that if you want to call from the browser straight back to a Thrift service without a gateway doing translation you can. This enable a single high performance path all the way back to the browser when the application demands it.