In a perfect world, maybe.
In reality: no.
Keep in mind that 1) the wiki is not an official place to communicate any project goals (in fact, I myself assembled the page you are referencing above) - also, 2) just because some core developer(s) state their wishes, that doesn't automatically imply any urgency/priority or even a "consensus" among core devs in general, that something is agreed upon and being worked on by others, or even just encouraged by others.
3) cppbind is a self-contained component, it using boost under the hood has nothing to do with its code being widely used by other core code - in fact, even if you were to replace the boost parts in cppbind, the functional interface of it would remain 99.9% identical (especially with modern C++ idioms).
Realistically, "deboosting" FlightGear/SimGear isn't going to happen anytime soon, unless additional core devs consider the current situation a problem, and get involved in addressing the issue. The background here being, that over the years, using boost has actually been encouraged by some core devs - in fact, in some of my own merge requests, James himself reviewed my patches and requested that I'd use boost constructs instead of standard C++ ...
All of which is to say, priorities are changing over time - and just because people tend to share their wish lists in a more or less public form, that doesn't commonly affect the way the project is running or being worked on - I mean, let's face it, we have something called the "project roadmap" with a bunch of items on it, that are really only being worked on/backed by a single contributor - which is why some stuff has never materialized over the years, despite being widely promoted (think the HLA/RTI development), or why other stuff is taking years to materialize without anything being visible, despite numerous public announcements that feature X/Y/Z would be about to be finished "soon".
You only need to look at the PUI dilemma: everybody and their dog basically agrees that PUI has to go, but very few people are interested in contributing to that portion of the work - and the few that are indeed interested in contributing to address the situation, are interested in different approach - such as modernizing PUI, replacing PUI using Qt5/QQ2, creating Phi or instead using a Canvas back-end to translate existing dialogs - with the Qt5 replacement having been announced to be almost ready for release for several years now:
https://wiki.flightgear.org/PUI#Replacement_statusNevertheless, it would be shortsighted to stop maintaining PUI/XML dialogs, just because the Qt5/QQ2 solution might become available "soon" - in fact, had we done that, none of our dialogs would be actively maintained because of the situation.
While that may sound a little irritating, that's unfortunately how things work behind the scenes (and have been working for years) - and even if you were to ask on the devel list, you won't find a single core developer there to suggest that you stop using/contributing to cppbind just because it happens to be using boost - that's akin to asking people to stop driving cars unless they own a Tesla
Seriously though, there are a bunch of important items that more people have on their own agenda because these translate into tangible improvements (compositor, composite-viewer etc), rather than "nice-to-haves" like reducing compilation times or getting rid of boost - especially because the exact same people who now want to get rid of it, have been pushing for its adoption for years.
The external cppbind interface is basically going to remain unchanged - and basically you cannot replace/update cppbind without wider test coverage, because it's widely used by many critical canvas components - basically, cppbind is there to stay, just like the canvas is there to stay - just because some folks don't agree with stylistic matters or dependencies, that doesn't magically mean that we'll have contributors interested in updating working code that happens to be fairly complex, too.
In other words, the one benefit that can be had from getting rid of boost in cppbind is reduced build times, and maybe more standard use of modern C++ constructs - however, even the recent push for wider adoption of modern C++ has been causing some friction among contributors.
Either way, getting rid of boost in cppbind isn't critical at all - there are more urgent issues, and you'll be hard pressed to find a single core devs to suggest that cppbind shouldn't be used currently just because it happens to use boost: whenever you're using a Canvas based feature, you are automatically using boost, too.
And that's also the crux of it: developers are generally not motivated to update working code just for sake of it, there must be an actual optimization/improvement. Which is hard to even just ...imagine in the case of boost/cppbind - build times typically don't matter to people on multicore systems with 64+ gb of RAM and 16 cores
Also, the way cppbind is structured, it being used by FlightGear (it living in simgear!), has nothing to do with "untangling" things: boost is internally used by cppbind, i.e. behind the scenes - so, you can definitely deboost cppbind, without modifying the external interface significantly, let alone breaking it entirely (cppbind being a way to expose data structures between Nasal and C++, basically sitting in between the property tree and scripting layer)
All that being said, most of the original FGPositioned APIs are predating cppbind by several years, which is to say that code was written (by James!) years before the canvas and cppbind showed up in the archives - which in turn means, you can also contribute to the FGPositioned side of things, without having to tinker at all with cppbind.
... that however, would be more tedious - as in having to write 100 lines of C++ code to accomplish something that cppbind will do with less than 20 lines - your choice