But that is what MikroTik is doing all the time! They started out using Linux and a number of open-source packages, but they are replaced one by one with in-house solutions.
Maybe they did not like open-source that much after all (remember how they were called out for distributing modified open-source software without releasing the changes they made as sourcecode), and also of course there is the challenge of fitting everything in 16MB of flash.
See the recent trouble with the DNS resolver. They are trying to re-invent the wheel of a DNS resolver with some local DNS server capability, developing it all themselves and running into the well known problems (DNS does not work like you would guess it does, it is one of the oldest protocols still in use and has a lot of ideocracies). The past couple of releases they managed to break it every time.
An open-source alternative that does exactly what they need (and what they still have to develop, such as DNSSEC support) is available: unbound. It has a very elaborate regression testing facility, likely made after a lot of similar problems occurred as MikroTik are having now. But they are stubborn, they won’t use unbound, they continue with their own development. Now, a typical unbound binary for other systems is ~1MB in size, so they may not have the space available to use it.
And who does not remember OpenVPN? Instead of using the open-source OpenVPN program, they wrote their own subset implementation years ago and left it as it was, while the open-source version changed and got new features, that were asked for time and time again. But nobody inside MikroTik wanted to touch the software anymore (I once read), and it had to be re-done for v7. But now it still is not complete and still has bugs. Using the open-source code apparently isn’t an option, or all trouble would have been over.
For BGP (and OSPF?) it is the same thing. Now, here they may have had a point in that they wanted a multithreaded implementation that could run faster on multi-core processors. After all, on their 72-core CCR1072 beast, only a single core was used by BGP. Also they wanted to reduce memory footprint and have some other new features.
But, as every experienced developer knows, such projects are always more difficult than it initially seemed. Features are forgotten in the design, and at first release people ask to implement them but that turns out to be more difficult or impossible (here I am not thinking about BFD, but things like “received prefix count/limit”, route aggregation, advertisement of not-actually-existing routes), and conversion of old configuration is also difficult (leaving “just clicked upgrade” users with problems).
And worst of all: over time the new routers have changed to having smaller number of faster cores, so the whole exercise probably was for nothing anyway.
I have studied the BFD RFC only briefly, but my opinion is that the simple case we all want, the link monitoring of a single-hop link using UDP packets, is quite easy to implement.
But it looks like either someone is trying to do a full implementation and holding it back until it is complete, or in fact the developer that is working on it does not spend any time on it at all, for some unknown reason (he has other things to do, he is on sick leave, he has left the company, whatever).