This behavior is not the same as Microsoft's TreeViewItem.
If I host let's say multiple RadTreeView in a Docking system, each in a different RadPanel where each TreeView is contained in a UserControl with FocusManager.IsFocusScope = true (this is important for proper RoutedCommand routing), then as I select a node in each treeview and activate different panels, the highlighted "focused" state stays on, they don't turn to gray. I find this very confusing in the UI because now you don't know which treeview has actual focus (other than seeing which panel is active.) Press an arrow key, hmm, I wonder which treeview's will act upon it. :) We also have a mixture of WPF controls and your Rad controls, so they are dealing with lost focus with selection in inconsistent ways.
(This actually occurs for all your controls, like RadGridView and RadPropertyGrid, but I'm picking on the radtreeview for now.)
The main question is: Was this intended behavior? If yes, then I guess I'll move on, sadly (maybe change your source code). I might then ask why you wanted to deviate from Microsoft's default behavior, since generally I'm seeing an effort in most of your controls to try to emulate the WPF controls pretty closely (at least the simple ones :)). Or why you didn't want to provide a property to choose between this behavior or the default (Microsoft) way.
For tech talk, if you use ILSpy and look at WPF's TreeViewItem.ChangeVisualState(), you'll see that Microsoft is looking at IsKeyboardFocused to determine whether to highlight or gray out a treeviewitem. In your RadTreeViewItem.ChangeVisualState(), you are checking IsFocused, which is logical focus, not keyboard focus. That's why all my treeviews show a highlighted blue selected node at the same time.