If you're okay with IE only, I like the IE hosted control's security model over Active-X, however, as of 1/1/09, Microsoft deprecates the use of .NET (in process) to extend IE so XBAP is okay, but not in ActiveX controls or IE Hosted controls.
Edit: W/o tweaking the registry, IE8 will only load a .NET hosted control from the intranet or trusted zone so for general internet use, Active-X is required for in-browser full trust access.
I find this both ironic and proof Microsoft is too large to even internally communicate strategy. The problem of using .NET under IE is caused by COM interop being hobbled with the limitation that only one version of the CLR can be in memory at a time. However, at the 2008 PDC, Microsoft announced that 4.0 will support side by side with 2.0 (in process) http://blogs.microsoft.co.il/blogs/sasha/archive/2008/10/30/pdc-day-3-what-s-coming-in-clr-4-0-part-1.aspx making COM interop a viable general solution for writing COM/Active-X controls.
This is a little late in coming since VB6 support was dropped last year, forcing C++ to be the only MS technology for writing COM controls.
To follow up on Russ's post: Silverlight can't access the clipboard: http://silverlight.net/forums/t/13024.aspx
Most of the IE hosted control information is in blogs so I use: http://www.google.com/search?q=ie+hosted+control+site%3Amsdn.com to find them. Below are the ones I've found particularly useful.
Quick and easy control: http://blogs.msdn.com/mikechr/archive/2006/11/28/writing-a-simple-managed-control-under-ie.aspx
Odd thing about security, unless the "evidence" is a url, the assembly may be trusted, but not the domain, requiring asserts to fix: http://blogs.msdn.com/carloc/archive/2006/11/01/code-access-security-hosting-control-in-ie.aspx
This is "fixed" in 3.5 with manifests. It's complicated to get right so see the instructions on using manifests from Shawnfa's .NET Security Blog for the .NET 3.5 Beta and post GA .NET 3.5. Todd's Random Discovery blog also documents the steps for creating a manifest for a hosted control
I found this useful from a KB article on setting up the security, but you'll still have to learn quite a bit about CAS: http://support.microsoft.com/kb/892466. This is probably the main consideration when deciding to use a (.net) Active-X vs an IE hosted control - that is, what security model works best for you and your users. My hope is that using manifest will make IE hosted controls work like click-once where the user is asked to "trust" and the correct settings are created by the system. For my company we used could automate setting up the security for the user so an ie hosted was our choice.
The one thing I never figured out was if I did or didn't have to inherit from (User)control for a ui-less control. It worked better for me to do so, but I had to "hide" the div the object tag lived in.
It's easy to debug the control if you compile for debug and attach to IE for "managed" debugging once you get the control to load. If you can't get the control to load, look up info on the fusion assembly binding viewer: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx and how to turn on IEHost tracing: http://support.microsoft.com/kb/313892 in order to debug the load process.
Be sure to version every version of the assembly. If you don't, then IE gets confused and won't load the control when the assembly in the download cache is different but has the same version # as the one the url references (gacutil /cdl clears the .net download cache)