After looking into this, from what I can tell, the http_api_transports filter doesn't appear to be in use anymore when using the normal wp_remote_* functions. I suspect it probably is if you call WP_HTTP_Curl::request() directly.

To me, it appears that it's no longer possible to disable the curl/streams handlers in Requests, I actually suspect it might not have been possible to disable them previously either; but because the curl and streams extensions weren't loaded, it was falling through to the Fetch handler.

I'm not seeing a filter in Requests to specify the transport to use either:
https://github.com/WordPress/wordpress-develop/blob/8448d06c49ade781ff6971054d79a84d90dc54ff/src/wp-includes/Requests/src/Requests.php#L225-L259

I suspect, the way forward is to get a filter into the Requests class; or have playground overwrite/modify the add_transport() function to allow us to load the Fetch handler ahead of others:
https://github.com/WordPress/wordpress-develop/blob/8448d06c49ade781ff6971054d79a84d90dc54ff/src/wp-includes/Requests/src/Requests.php#L205-L216

Example:
https://playground.wordpress.net/?php=8.0&networking=yes&plugin=debug-bar-console&plugin=debug-bar&wp=6.4&storage=none&php-extension-bundle=kitchen-sink&networking=yes

I think I found a workaround.. there is a generic filter that let's us change some of the basic Requests args, and it includes an option we can use to force a specific transport to be used:

add_action( 'requests-requests.before_request', function( $url, $headers, $data, $type, &$options ) {
	$options['transport'] = 'Wp_Http_Fetch';
}, 10, 5 );

Here's a request with, and without the above filter:

Note I've merged a reflections-based fix around the same time this issue was reported, but I think @dd32's PR is a more elegant solution and I'd love to move forward with that one instead.