Actually, there may be a use case, but it is a little contrived and depends on
how the CSRF token is generated.
In many cases, the CSRF token is just a random token which is tied to the
session and is not related to any level of authentication. When the client
requests a page containing a web form, the form has the token embedded in it as
a hidden field. When the client posts the form data, the server verifies the
token is the same as the one it sent and can be fairly confident the response is
from the same client it sent the form to. All good.
However, this work flow is less convenient in the context of a web API where the
initial contact with the server is from a client who is posting some data (often
in the form of some JSON). In this case, the server has not been able to send a
token. Normally, a web api would have some other sort of verification - for
example, you use JWT, the client app will make an initial connection to the
server where it performs some authentication and gets a JWT which it uses in all
future API calls.
Often, this is not an issue as you will have separation of concerns. There will
be a set of URLs used by a web client which follows the normal request a form
then submit the data work flow and a separate API URLs which use something like
JWT. There is no need for a CSRF token.
The problem can be when you have vary similar requirements for both. You really
don't want to have to maintain two separate sets of handlers and would prefer to
just have the one which can be used by a traditional web client and also as an
API client. In both cases, a token is used, but they are different in nature.
I did say this was contrived. In reality, I've only come across this sort of
issue when developing a new service where I wanted a web client interface as
well as the API just for development/debugging purposes. In this case, what I
initial authentication with the server and gets the JWT which it copies into the
web form as just another value. However, I can imagine a situation where you
want to support a general web browser based 'traditional' interface and a
application which uses HTTP/HTTPS for communication via an API.
To some extent, this is really just semantics. The basic concept of providing a
token in web forms to protect against CSRF is not vary different from an API
which is using a token for authn/authz purposes. The only real difference is
that the CSRF token usually doesn't imply anything more than the fact the
response is from the same client the initial form data was sent to while the API
token is making assertions about the actual user. Technically, there is no
reason the latter cannot be used for the former, provided the server can handle
that. The former cannot be used for the latter.