Rocky Lhotka claims WF is complimentary of his CLSA.NET framework. His argument can be actually applied to any rich object framework where you put your business logic inside your domain model.
I don't think Workflow by itself will have an impact on those kind of frameworks, but Windows Workflow could (or should?) have it, not because the Workflow engine but because the Business Rules engine.
When OOP started, the idea was that we will have a class that will be responsible of all the behavior of the related real-world entity. The Customer class would know how to persist itself, how to print itself, how to display itself, etc.
Later, we decided to separate the concerns, and we had the 'Customer Views' to handle the UI logic, the 'CustomerRepository' to handle the persistence logic, and the Customer itself, with the structure and the business logic. This added more complexity, as those classes needs to be synchronized (if I add something to the Customer class, I need to add it in each view, the database, etc), but the reality is that today this is the approach that the industry seems to prefer.
However, why should we keep the business logic in code? Code is hard to change, and business logic changes a lot. If we can have an engine to run business logic, it will be possible to change it easily, even by the end users (as ILog for .NET allows).
Check the Rules Driven UI Example in the Windows Workflow site. Even if that example is not very good from an design point of view, as the rules act on the UI controls, it could act on any .NET object that is bound to a .NET control. For example, you could execute the rules over a DataSet, set the Row errors accordingly, etc.
I don't know how far does Microsoft wants to push the Business Rules Engine, but if they decide to create a world-class engine (I don't have enough experience with the current implementation to know how good is it), then I'd tend to write all the business logic that's possible to write using it.
Now, if you mix this with the fact that OO isn't very good in dealing with Data Structures then you could start worrying about the future of rich object frameworks ;).