если объект наследует ICommandSource (BaseButton и её наследники или др.), то у него есть свойство Command, можно сразу на него биндить команду, если это позволяет реализация модели, но к примеру если это просто сущность (элемент ListBox) то у него может быть не быть реализован в модели обработчик команды ICommand (ты же не можешь удалить Person из самого Person), тогда я к Command (например кнопки) задают маршрутизируемую команду и обрабатываю её на том уровне, где этот обработчик реализован. Как в примере, у Person нет ни каких команд, команда есть в MainModel, и именно эта команда вызывается при нажатии на урну и удаляет Person из коллекции.
То есть для любой команды пользователя в UI будет реализована соответствующая команда в модели.

Shocker.Pro,

смысл в том, что вся интерактивность должна оставаться в рамках View, то есть, если нам нужно сделать, к примеру, обработку на кнопки KeyDown, то мы просто добавляем AttachedProperty или через Interactive соответствующее поведение.
В результате выполнения этого поведения должна быть вызвана та или иная команда (либо маршрутизируемая, либо обычная, которую мы получим из свойства которое так же приатачим к этому элементу управления).

Передавать события в VM не нужно, в этом нет необходимости, все события View должны обрабатывать на том же уровне.
К примеру, нам надо сделать DragAndDrop, соответственно в представлении (во View) я создаю класс с прикрепляемым свойством
IsCanDrag и привязываю это свойство со значением True к тем объектам, которые я хочу перетаскивать.
В методе OnChanged для данного AttachedProperty, если значение равно True я подписываюсь на 3 события MouseDown, MouseMove, MouseUp, где определяю логику захвата данного элемента управления для перетаскивания и вызывают DragDrop.DoDragDrop().
Для объекта в который идет перетаскивание создает свойство IsCanDrop, где так же добавляются обработчики на события Drop и др.
И свойство DropCommand которое будет связано с командой которая будет вызываться по завершению перетаскивания.
То есть вся логика, отвечающая за перетаскивание объекта лежит на View, а не ViewModel, а все её ньюансы настраиваются через свойства и связывание. В результате я могу применять это поведение практически к любым элементам управления.

Так же, не нужно пренебрегать наследованием. Очень часто я делаю свои контролы с нуля или наследую существующие, в которых определяю всю логику их работы, но как и в первом случаи сам по себе контрол ни чего не знает о ViewModel, у него есть набор DependencyProperty через которые и настраивается его поведение и внешний вид.
То есть сам контрол делает с расчетом на том, что он ни чего не знает о классах модели представления. Сам контрол взаимодействует только со своими свойствами и инициирует выполнение тех или иных команд.
Маршрутизируемые команды можно просто выполнить в код как "Команда.Execute(параметры)" и она тут же всплывает из того контрола в котором её вызывали. Контрол должен быть инкапсулированым и полностью самодостаточным.

Если мне нужна сложная логика размещения\компоновки элементов управления, я создаю свою панель, прибегаю я к этому не часто, так как существующие панели (при их комбинировании) дают довольно широкий спектр возможностей для компоновки

Если прямого взаимодействия между View и ViewModel невозможно избежать, то можно использовать Interface'ы, модель представления реализует заданный интерфейс, эта модель биндится к заданному свойству, элемент управления во View проверяет, полученный объект на и дергает за нужные методы\свойства\события этого интерфейса.
Такой подход реализован в INotifyPropertyChanged, ICollectionView, INotifyCollectionChanged, ICommand и всех это устраивает. Ведь такой подход остается униварсальным.
Вы знаете, что есть контрол для которого в 1 из свойств передается соответствующий интерфейс, вы его реализуете прикрепляете и всё в шоколаде.

когда мне надо быстро, без заморочек с подключением сборки Interactive я использую AttachedProperty, а так как я ленивая скотина, я использую его в большинстве случаев, так как это просто, удобно и главное понятно, я же могу быстро посмотреть что задает это свойство, видно, что оно не "родное". + я могу определить, что данное свойство влияет на пересчет размеров, компоновки и рендеринга.

очень часто приходится сталкиваться с низкой производительностью чисто декларативного подхода, тогда приходится создавать свой собственный контрол, который будет сделан на основе Visual объектов, но тут нужно подходить с умом. Знать когда использовать Visual, когда UIControl'ы, каждый UIControl наследуется от Visual, но поверх там наколбашено очень много всего.
Производительность Visual на много больше, но возможностей у них на много меньше. Мы по сути, можем определить только как выглядит объект, и где он находится, всю логику взаимодействия нужно делать в рамках класса (например) Control.
Visual объект можно поместить в UIElement, но UIElement нельзя поместить в Visual (не считая VisualBrush и BitmapCacheBrush, да и за помещение это назвать сложно). Но можно создать визуальное дерево самих Visual объектов, если в этом есть необходимость.

Shocker.ProРоман, по твоему опыту - есть ли принципиально ситуации, где ViewModel требуется наследовать от DependencyObject (чтобы создавать свойства зависимости) или во всех случаях достаточно INotifyPropertyChanged?
такого не было :) и не будет.
возможно просто этому свойству место во View, в не во ViewModel.

Если свойство контрола (во View), не DP, а обычное, то возникает проблема связывания.
ак как невозможно связать вместе два обычных свойства, тогда, обычно, используют Proxy класс который будет осуществлять это связывание.
Но тут возникает еще несколько проблем:
а) в свойстве контрола, при изменении может не вызывается INotifyPropertyChanged.OnPropertyChanged, следовательно через Proxy всё равно нельзя будет обновить значение во ViewModel, если оно изменится во View
б) такая канитель сильно запутывает код

по этому такими вещами редко страдаю, я даже отказался от SelectedItems свойства (для примеру) у ListBox. Вместо этого, у меня для списков есть обёрточный класс, он сам оповещает меня о том, что выделение изменилось, как только у одного из элементов списка свойства IsSelected изменится, при чем, если оно изменится не у одного, а у нескольких элементов (когда выделение Single, с одного элементы IsSelected становится False, а у другого True), то я всё равно получу один вызов события, а в событие сразу передается список выделенных элементов, через Dispatcher