"Why should you put a 10 foot pole between yourself and technology?
Well, because Microsoft (or insert vendor of your choice here - they’re all equally guilty of this) tend to deprecate (as in kill) the technology they evangelised just last year/month/week.
Microsoft Sql Server Notification Services are the latest victim.
I hope you don’t have any application code tied to that technology." 
Here is yet another example of why you need proper abstraction. When designing your application's layers, expose as little of the implementation details as possible.
For example, if you are going to be using Windows Workflow Foundation to handle the workflows for a complicated system, that is fine... but try not to expose the workflow instance or activities directly to clients. If for some reason you need to ditch Workflow Foundation, you don't want to have to rewrite every component that utilizes workflow for it's operations. Instead of a method like this:
void ShipProduct(SequentialWorkflowActivity shipmentWorkflow);
Have a method like this:
void ShipProduct(IProductShipmentProvider shipmentProvider);
Behind the scenes, you might create a framework for handling these shipments using Windows Workflow Foundation, but keep the implementation details behind the scenes instead of exposing them to your callers. Then, not only are your clients protected, but your server code is protected as well. If at some point you decide that you really need to be using Biztalk for your workflow, you can start using Biztalk immediately for new implementations without rewriting all your current workflows first.
This also applies to communication with external systems. If you need to interact with an external system, provide a service that accepts data in a format that your system is familiar with, let the service implementation deal with mapping between your data structures and the external system's data structures. This way, you are free to roll out fixes to your communication or support for new systems without rolling out anything else.