I have no doubt that the primary developer(s) of the staff view have long since left the company.  I also don't question their ability to start a company based on their knowledge of staff-based notation products, which obviously has happened.  What I do question is that departure having a substantial impact on Cakewalk's ability to modify the staff view.  Maybe the dude retained rights to develop it into his own external product, and even THAT would be rare in the programming world, without rewriting it from scratch on his own (not impossible, just a lot of work).  But for a programmer to jump ship and prevent Cakewalk from improving (or even fixing) the staff view to which they obviously still have distribution rights, is really far-fetched.  
 
That's why I don't buy the argument that the original programmer has, or had, anything to do with Cakewalk's neglect of the staff view, without some sort of really solid proof they they only have rights to distribute his work in the state it was created, without modification.  I would posit that even the modifications we've seen over the past 15 years, though minor, would void such a contract.  
 
Thus, I maintain that the staff view exists as it does today not because Cakewalk is somehow prevented from working on it, but because there hasn't been financial incentive to do so, and more recently, drive to overcome the inertia of working with VERY old code.  The longer it sits, the more effort it is to untangle.  
 
But hey, now that Ripple Edit is out and the PRV has gotten 2 months of improvements and Sonar has every 3rd-party plugin and other bell or whistle one could imagine, like touch support.... perhaps there are secret plans for the staff view.  I will always hope, but keep breathing just in case.
 
And I still like the philosophy behind the staff view as it is and would be wary of a 3rd-party integration.