Look here this present the pattern Model View ViewModel, this permit you to take full advantages on the binding, and Command of WPF, without disturb your business objects (like implementing WPF stuff like INotifyPropertyChanged on your business objects)
I would suggest that you do your port in stages to make the transition easier. The first stage would be to port from VB6 desktop to .NET desktop (win forms).
Then in the second stage, if still needed, you move all or parts of the .NET desktop to an ASP.NET GUI.
The step from VB6 to .NET is in itself quite large for a team to make, regardless of GUI choice. The staged approach would allow your team to get to grips with .NET in an application style more similar to the current app.
Your goal to separate business logic into re-usable libraries is therefore important for this staged approach to work. If you take this approach, you have much more flexibility about the GUI type (or types) used.
For example you could have all simpler screens provided in an ASP.NET website, with an auxillary WindowsForms app containing more complex screens that users can download as required. Importantly both of these would use the same business logic libraries, they are mostly just different interfaces to the same application.
ASP.NET (or web development in general) requires a quite different developer mindset when dealing with state, cross browser, html/css etc.
I recently worked on a port/migration of a large Delphi desktop app to .NET. The goal was to go to ASP.NET, however this fell over completely because the existing team had limited web development experience and tried to just re-implement the dektop app using ASP.NET. I'd say that this is a much bigger risk when compared to re-creating screens in Windows Forms, at least the end result will be usable and provide end-users some value.
While Ajax and jQuery have made great improvements to the richness of web GUIs, it sounds like your the existing app has some areas such as spreadsheet presentation of data that would be easier to implement efficiently in a desktop app.
In summary, the "ideal" is to move the business logic and rules to .NET in such a way that you can then simply "plug-in" a user interface at a later date. This may be much easier said then done, but that is the goal I normally aim for.
Best Solution
For my team, WPF has proven to be much faster than WinForms to develop applications with. We recently released a mid-sized app in 32 man days. We had the advantage of an experienced WPF developer on the team, and inexperienced guys who were eager to learn the technology. There was great morale, and productivity was impressive.
Do you consider yourself a hand-coder, or a drag-and-drop coder? If you consider yourself a drag-and-dropper, than the current crop of WPF tooling may not be suitable for you. Maybe wait for Visual Studio 2010? I work almost exclusively in XAML. Most WPF'ers will probably agree that this is the most effective way of creating WPF applications at the moment. But then, I also craft my HTML by hand, so it feels natural to me...
I used to think this way, but I have recently developed a business application which has gradients, basic animation and effects. These fancy features were added to enhance the user experience. Why should business apps be Battleship Grey? Why should they be unusable? Granted, it isn't color, gradients, animation that makes a business app usable, but using these effects can help the user experience, and this is what is important to me. I could have done everything I did in the WPF app in WinForms - it just would have taken much longer.
The databinding support truely is amazing. It is my single most-loved feature in the platform. Check out this wonderful Databinding Cheatsheet.
I have decided that I am not going to try and convince anyone else to switch to WPF. The developers I have tried to "convince" (all experienced Winforms developers) usually have struggled with the platform. They are not invested in the technology. They don't "get it". I encourage people to check out the technology to see if it is right for them as a developer. The learning curve is huge. If you learn by books, check out this SO post for some mini-reviews on WPF books. If you learn by videos, check out the windowsclient.net WPF videos. If you learn by example, check out this or this post. Forget everything you know about WinForms. WPF really seems closer to ASP than WinForms. Create some sample applications. See if it works for you and your team.
As you are multi-skilled (asp.net/winform skills), you may see the advantage of skilling-up in WPF as it is very closely related to Silverlight. Silverlight fills that gap between your rich client applications and web applications.
I personally feel WPF is the best client side technology available for the .NET framework, and will generally avoid developing in WinForms for future work. YMMV
Good luck with your decision.