TL;DR
The following is a kind of ‘brain dump’ of thoughts about why such a feature isn’t really worth it (IMHO) – which may or may not be interesting for some folks to read and consider (it applies to more than just this specific feature; it’s about software development in general). I have also not edited it down for brevity, so it will be a bit rambly.
If this kind of rambling thoughts are not interesting to you, feel free to ignore. It’s not a direct reply to your exact comment, more of a general feedback on the overall sentiment of your (and others’) comment(s).
With that disclaimer out of the way, allow me to ramble 
…
The overall idea: From specific to general
Overall, as a general feature, the WK furigana sync is a kind of ‘blanket’ convenience thing which has many ‘edge cases’ peeking outside of the edge of the blanket – so to speak 
.
In order for Bunpro to perfectly cover all those edge cases (say, in some ideal world), the BP team would have to create a system which synchronizes not just the status of “are these kanjis at Guru level on WK”, but also track things like “which WK vocabs teach this kanji’s kun’yomi (or whatever specific reading), and have any of those vocabs gotten to Guru level yet”, and check that kind of condition for each kanji.
Now, that alone may be possible – though perhaps of dubious additional benefit, but we are considering a kind of ideal-world situation. But on top of that, they would also have to track any/all of the changes that WK makes to its system, such as changing the ordering of which kanji/vocabs appear at which levels, and probably several other edge-case-specific conditions that aren’t immediately coming to mind right now.
All of this is theoretically (and to be honest, even ‘practically’) possible, in an ideal-world situation. But it would be quite complex to program and implement, and some components of it would probably not be able to be fully-automated – in other words, Bunpro would probably have to have someone monitoring the WK website for various changes to their system. For example, WK often posts updates in their forums about upcoming and ongoing/completed changes to their items: Additions, removals (rare, but they happen), level re-assignments, primary readings (also rare, but happen), etc.
All of this is to say that, again in an ideal-world situation, such a feature that would perfectly cover all the edge cases is possible to create.
The issue, then, comes down to cost, time, priority, and other such non-ideal-world constraints that any development team is going to have to contend with. And ultimately, the question is: Will it really be worth all that effort / those resources spent for the resultant benefit to the customer/user (and hence to Bunpro as a business)?
Often, a good way to handle such situations – where a feature-set is technically possible, but practically too costly to fully implement – is to try to address the most urgent/important needs first, with a minimal cost, and to defer the less urgent/important & more-costly needs to some unspecified future time (planning for all future features is also costly and has diminishing returns).
Thus, some system of prioritization is needed. A good, common strategy for prioritization is to rely on the Pareto Principle, aka the 80/20 rule, which I’ll paraphrase as “You can get 80% of the job done with only 20% of the resources. Conversely, the remaining 20% of the job will require the remaining 80% of the resources (i.e. 4 times the cost of the first 80% of the job!!!)”. Of course, this is just a rough guide. It might be more like 70/30 or maybe more like 95/5.
How this applies: From general back to specific
And so, to wrap up, I see the current Bunpro feature as a good example of this kind of Pareto solution: Detecting whether a kanji on WK is in Guru state is very easy to implement and, crucially, to automate; and it covers 80% to 95% of the feature. To catch more of the edge cases would require proportionally a lot more development (and maintenance!) resources.
And they have indeed added to this initial feature, which is to allow all instances of furigana-capable words to be manually switched on or off as each user chooses. This feature I’m fairly sure required quite a bit more development/maintenance resources to implement (since it requires not only the UI for it, but also to code for handling conflicting ‘signals’ where WK-sync and user-preference differ; not a huge deal, but not nothing either).
And, as is often the case with Pareto Principle situations, this additional feature itself solved something like 80% to 95% of the previously-unsolved edge cases, again with 5%-20% of the resources required. Ish. Again, it’s just a rough principle. In other words, the Pareto Principle often ‘stacks’ or ‘nests’ itself.
Conclusion: The actual point
While BP could devote more resources to this furigana feature, I think it would be challenging to justify investing much resources into it. The current solution covers most cases quite well, and they even have a quite-functional ‘customizable’ system for handling user-specific tweaks and/or workarounds.
Of course, I could be wrong, and maybe there are additional features which could garner a lot of user/customer support, which would then justify spending more investment on improving it further. (I’m not intending to discourage such feature requests/suggestions; they’re great and welcome!)
Until then, though, I think this feature provides a good example of well-managed compromise (go Team Bunpro! 
) between what’s possible (ideal, ‘perfection’) versus what’s satisfactory (practical, ‘good enough’). That’s just my personal opinion, though!
[Besides, the Pareto Principle is just a cool phenomenon in general! 
]
Cheers!
