The Bela project started in 2014, and there were not many tools available out there at the time, so the first writing of the PRU code was done in assembly. The same code was later expanded to support new peripherals and features, but it is still written in assembly.
If we were to do it from scratch today, we would probably still use assembly, at least for the long
If the code for your specific PRU application is not so time critical (e.g.: it can accept jitters in the order of a few microseconds), then I am sure these tools are a great way to get into PRU programming, and can give you a head start. It seems like the Cyclops IDE can also " automatically configures the Beaglebone’s pinmux controller to use common I/O peripherals". If you use it, be careful that these automatic settings don't override any of the finely crafted pinmux settings needed for Bela to run. Also, make sure that the Cyclops IDE itself allows you to run an arbitrary piece of software on another PRU, while you control one with Cyclops: you wouldn't want it to take control of the whole PRU subsystem and prevent the Bela PRU firmware from running. Additionally, be aware that the Bela code uses all of the RAM of the PRU it is running on and all of the RAM shared between the two PRUs. It doesn't, however, use the RAM that belongs to the other PRU. Will Cyclops do the same?
You can see from the paragraphs above the type of caveats there are when using higher-level tools that make on-boarding more user-friendly. This is yet another good reason for us to stick to PRU assembly for the foreseeable future, when developing the Bela core. However, please feel free to experiment with more user-friendly tools, I would be happy to hear more about that, but be aware that - if you cannot control them with fine granularity - they may end up getting in the way of the basic Bela functionalities.