The consensus is that physical developer hardware is best managed by developers.

The 'problem' of managing 'large numbers' of 'commercial software licenses' is not a problem with automation; unfortunately it goes against the grain of developers managing their own hardware.

It seems the real problem in the OP's organization is management unwilling to delegate and constantly searching for centralized solutions to trivial 'problems'.

Normally in a centralized system you would hook up CI/CD processes to dedicated infrastructure, so that when developers commit to your RCS/VCS server (github, gitlab, whatever else), builds and tests are automatically run.

This infrastructure may be a dedicated system, a cluster, or outsourced infrastructure (real or virtual).

Because git (or any other RCS/VCS) is a well defined formal interface between the developer and the rest of the development-related business processes (automated or otherwise), it means individual machines can just be user managed, which developers tend to prefer.

It's worth mentioning that there is a school of thought that builds or tests that take longer than a few seconds on a developer's machine are undesirable from a workflow optimization perspective and may be indicative of a non continuous delivery (CD) capable codebase, with probable features such as knowledge silos ("only that guy knows"), undeployability, low quality, lack of project visibility, infrastructure tie-in and late defect discovery.

If you have to wait 1h for testing feedback it kills the development inertia.

And so do slow development tools, compiling something for 2 h and then getting negative feedback is not cool, and yet this is something I've seen happen at my current job and it drives me insane.

You could consider an on-demand cloud-based compile farm, or incremental builds with snapshots.