And no, a depgraph doesn't make it fast. What can make it fast is firing less events, using better triggers, and basically handling it exactly the way that Angular didn't.
VDOM can help, but really not much. However you want to put it, two-way binding is costly, and it should be avoided whenever possible, or minimized by catching multiple bind events at a higher up element on the tree (see http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi...)
Just spraying it everywhere, the way Angular encourages, with no optimization (like the aforementioned asymetrical bindings), should be considered an antipattern.
In any case, Computed values make 2 way binding more expensive, because you have to run a depgraph on all the vars that are part of the binding network, every time an event fires. This is O(n). This is only one reason why Computed Values, as implemented in JS, are a Bad Idea. If you have to update a var on event fire, okay, but leaving the things everywhere is slow and ungainly. If you instead change the var to a function call, you can optimize far better, because you only have to update when the value is read.
In conclusion, if you want to polymorphism between functions and variables, treat everything as a function, not as a variable.
At least, I think that's a response to your question. Your English is pretty broken, so it's hard to tell. Sorry.
It's easy enough to write two way binding into a react state variable, it's just nice to not have it happen by default since having state able to change anywhere in the app can get confusing.
http://blog.ractivejs.org/posts/whats-the-difference-between...