Buenos Días:
Perdon por la demora en la respuesta pero ya estoy nuevamente en linea 
Definitivamente un buen punto a seguir son los patrones de van der Aalst. Lamentablemente no todos los productos (de bpm ó workflow) los cumplen a cabalidad. Para que funcionen toca hacer una ú otra triquiñuela que no es tan natural a la hora del modelamiento.
En cuanto al punto de Sharepoint, veo que he levantado alguna controversia con el asunto, no falta el que sataniza todos los productos microsoft ó por otro lado no sobran los evangelizadores que sin ganar un dolar hacen propaganda de dichos productos.
No obstante mi concepto es basado en la experiencia en la que tristemente he tenido que enfrentarme a los productos que menciono y con argumentos prácticos puede compartir a la comunidad los resultados en un ambiente empresarial, en el que los procesos implementados los utilizan cientos de persona, con procesos diversos y en los que se espera de estas herramientas su mayor desempeño.
La respuesta de porqué incluir a Sharepoint dentro de este análisis, es porque he visto como en herramientas comparativas de bpms que se encuentran en internet ó inclusive en forrester y gartner incluyen a sharepoint (con herramientas de terceros que precisamente desarrollan sus máquinas de estados sobre la famosa wfmc) como bpms. Como la intención de esta entrada es guiar a la gente que incursiona sobre el mundo del bpm sobre que opciones existen, no sobra mencionarlo.
Ahora bien, centrandome sobre el WFMC sin utilizar herramientas de terceros, tiene innumerables problemas haciendo que el manejo de máquinas de estados sea bastante limitado, muchos de estos problemas el mismo Microsoft los ha reconocido en sus innagotables KBs que deben ser instalados sobre la versión nativa de Sharepoint para conseguir que las cosas funcionen. Y desde el punto de vista de desarrollo se requieren demasiadas (por no decir infinitas) horas de desarrollo para conseguir cosas que en un bpm son naturales.
La evaluación de una herramienta basada en el cumplimiento de patrones suena como una excelente idea, no obstante, es una labor titánica dado que primero deberías conocer a profundidad el software, como modelar y construir la aplicación y luego proceder a la implementación de los N patrones y su comprobación para ver si cumple a cabalidad con lo que dice el patron.
Por otra parte y en contraposición con lo que dice Lionel, existen otros requerimientos tanto funcionales como no funcionales, que son de vital importancia a la hora de elegir un bpm adicional al cumplimiento de los patrones, el cumplimiento de los patrones es solo una arista del problema, a la hora de elegir un bpm se debe considerar otros aspectos tales como: desempeño, escalabilidad, seguridad, movilidad, integración... solo por nombrar algunos.
Por lo tanto es un error solo considerar una herramienta como la mejor porque cumple un patron que las demas no lo soportan. La elección de un BPM ó una herramienta de WorkFlows va mas allá de esto.
