there's some amount of coding needed to port a program to use Bela, as Bela doesn't use ALSA or Jack. See here for a generic writeup: https://github.com/BelaPlatform/Bela/wiki/Using-the-Bela-core-with-other-programs
Last year I had a brief email exchange with another ChucK user who had similar interests. My email was more or less like this:
We would be very happy to have ChucK run on Bela, however that is unlikely to happen with our effort alone. As none of us on the core team of Bela uses ChucK, we wouldn't be in the position of porting, testing and maintaining it without a significant community contribution and/or interest, at least to get it off the ground. Ideally, someone who is a ChucK developer would take the lead on this, and we would be happy to help every step of the way with integration. This approach worked very nicely for Supercollider, Csound and FAUST, and to some extent Rust, where some dedicated developers from the respective community took the initiative and did the heavy lifting, while we supported them along the road. If you are or know the right people (ChucK enthusiasts with an understanding of its low-level backend workings, and the time and willingness to get their hand dirty in ChucK + Bela), please let us know and we'd be happy to support that. Solving the audio backend is not the only issue, as there are some considerations to be made about how to deal with analog and digital I/O in a way that makes sense for the language at hand. Also, there will be some other ChucK internals (e.g.: threads and inter-thread communication) that will need an insider job.
Last, I am wondering how much the live-coding component is part of the traditional ChucK experience: while live-coding can be used for prototyping on Bela, it wouldn't be practical (or it wouldn't perhaps make much sense) to do it in a live / embedded instrument setting.
To this, they responded that they proposed the issue to the ChucK community and were awaiting a response. I haven't heard back and it's being about 6 months, so...