Likewise, this is my primary use case - using dns01 challenges to create LE certificates from cert-manager on a Kubernetes cluster. It seems a no brainer to implement this - I don’t like the idea of giving cert-manager full access to my DO account.

my use case primarily (for now) being "lets-encrypt" DNS access to TXT record read/write

Fine grained permissions is important for every public API, because you will inevitably be invoking it in less trusted contexts.  I would wager that most administrators consider their droplets to be a generally less trusted context than the administration control panel.  And the request handlers serving up http responses are less trusted still, that's why they run as limited users.  To give an API key with the full powers of your project administrator to a lowly request handler completely undermines sane access control.  Yet that must be what is happening on some systems. But it needn't be if only it were easy for users to do otherwise.

Permissions for each API method must be off by default, with it being up to the user to select which methods are needed.  Also you must be able to restrict by project, etc..

Until a system is in place that makes it easy to use API keys responsibly, I will consider all API-related security breaches to be the fault of DO for not providing the minimum tools necessary.  This goes for all public APIs, not just the management API.

I'd like the tokens to be limited to DNS management records.

Ideally, there could be also even finer permissions that allow a token to add/delete/update A and TXT records which are used by let's encrypt