The short answer to your question appears to be “yes”. Puppeteer announced support for Firefox last year (via BiDi) and AFAICT Tor Browser does not block this functionality. As I have been experimenting with Firefox’s BiDi support recently I thought I’d try it out.
If I start Tor Browser like so:
$ ~/tor-browser/Browser/start-tor-browser -l --remote-debugging-port
The default log file created at tor-browser/tor-browser.log contains the following entries:
WebDriver BiDi listening on ws://localhost:9222
DevTools listening on ws://localhost:9222/devtools/browser/3be2bf65-a0be-4d04-b8b7-dcaff5aab0b4
So far so good. I tried a proof of concept (with Ruby’s Puppeteer library) and the browser did try and navigate to the page I requested. I say “try” as I’ve not yet managed to figure out how to get the library to either use TB’s default profile or add prefs to a new one. extensions.torlauncher.prompt_at_startup needs to be set to false so the browser connects to the network at startup). As tor had not bootstrapped the above experiment resulted in a network proxy error - but this itself is proof that the browser did try and navigate to the requested page.
remote.active-protocols is set to 3 by default in the latest version of TB (as it is in Firefox 128 ESR) which means both CDP and BiDi are enabled. As you noted, CDP is being dropped and BiDi is definitely the way to go, especially with the new ESR release (140) due out in just 3 weeks now.
Programmatic control of Tor Browser this is definitely possible. There exists a Selenium library for Tor Browser for Python and I maintain a Ruby one myself on GitLab.
Best of luck with your project.
Update:
Connecting to the websocket address (derived as described above) of an existing Tor Browser instance worked fine. Puppeteer navigated to https://check.torproject.org and took the screenshot below 
