I think that depends very much on your MFC/Win32 API experience.  If you're
already proficient with MFC, then use it.  But if you're not, the learning
curve for WinForms (.NET) is an order of magnitude faster than MFC.  In .NET
1.x, winforms wasn't really "ready for prime time". lacking good support for
such basic things as toolbars.  But in .NET 2.0, it's quite possible build a
nice looking, globalized, "Designed for Windows"-compliant end-user
application.

Now, as for "taskbar notifications and stuff".  There's no direct support
for the shell notification area (aka taskbar tray) in winforms 2.0, but I'm
sure you can find any number of examples on the net of how to interact with
the shell notification area from a .NET application.  "and stuff" is a bit
harder, as it depends a great deal on exactly which "stuff" you're
interested in.  For example, if you need to implement any of the shell
extension interfaces (e.g. IShellFolder), then you'll have a very hard time
doing that from C# because there's no type library for those interfaces -
they're defined directly in C++ header files and basically unusable from any
other language.   For general Win32 stuff, .NET generally either already has
a nice wrapper (e.g. for the file API), or can readily use Win32 via
P/Invoke.

Lastly, you can always choose to build a hybrid, using C#/winforms for the
bulk of the UI and C++ for the meat of the application and for building
interfaces to parts of windows that aren't already well covered in .NET.

-cd

The main reasons (IMHO) for writing native C++ over C# are:

1.  The target computers don't have (and won't get) .NET installed.  Depends
on the hardware and corporate policies.
2.  The application needs to run extremely fast - usually for
computationally intensive time-critical operations.  Usually not a huge
factor for WinForms apps, although some of the functionality might need to
be tweaked.  You can always interop with native code for time critical
functions.
3.  The size of the executable needs to be extremely small (i.e., target
computers have very little memory).  Again not usually a huge factor.

I have to write a lot of back-end applications in C++ (native) and C#
myself, and I find that the C# apps are much easier to maintain over the
long haul.  The savings in maintenance costs and shortened development time
more than justify conversion and new development in C# in my situation.

For your customers without high-speed connections (if there are any), you
could probably snail-mail them your app. installation package on CD...