I have pushed quite hard for the inclusion of a DSP library with Bela in the past, for exactly the reasons described here; the frustrating fact that you have to go back to first principles to create a simple filter, and the gap in difficulty between the C++ workflow and the puredata workflows for higher-level coding.
The reason it has not yet happened from my perspective is mostly maintenance. As soon as we release a library, or even a wrapper for an existing library, we are on the hook for maintaining it in a bug-free state, and we simply don't have the resources for that at the moment. I also accept that embedding one particular DSP library in Bela's core is not a good option because everyone has a different library that they want to use.
However, I think it's unreasonable to expect beginner users to install a complicated third-party library themselves, especially as it can be quite challenging to connect the BeagleBone to the internet. Linking to compiled libraries is not straightforward for inexperienced C++ developers or linux users.
The best solution to all of this seems to me to follow the examples of platforms like Processing, who provide a dedicated library management system which allows users to browse a range of libraries that have been made for the platform, and download / include them as necessary. These libraries could be (mostly/partly) community-contributed and easily shareable, there could be a variety of DSP libraries, along with libraries for accessing system functions like I2C etc. At least to begin with, they would likely be wrappers which allow the use of existing libraries from within Bela in a convenient way, rather than our own reimplementations of anything.
I'm very interested in developing something like this to integrate with the IDE, but all of this stuff is quite a long way off at the moment as we don't yet have the infrastructure or resources for something like this. But rest assured, we are thinking actively about solutions to these problems!