R – Can a SharePoint list item have it’s Targeted Audience calculated or otherwise automatically specified

Include a content editor web part in the page (newform.aspx / editform.aspx) and use jQuery (or just plain javascript) to handle the setting of default values.

Edit: some example code:

In the lists newform.aspx, include a reference to jquery. If you look at the html code, you can see that each input tag gets an id based on the field's GUID, and a title that's set to the fields display name.

now, using jquery we can get at these fields using the jQuery selector like this:

By title:

$("input[title='DISPLAYNAMEOFFIELD']"); 

by id (if you know the field's internal guid, the dashes will ahve to be replaced by underscores:

// example field id, notice the guid and the underscores in the guid ctl00_m_g_054db6a0_0028_412d_bdc1_f2522ac3922e_ctl00_ctl04_ctl15_ctl00_ctl00_ctl04_ctl00_ctl00_TextField

$("input[id*='GUID']"); //this will get all input elements of which the id contains the specified GUID, i.e. 1 element

We wrap this in the ready() function of jQuery, so all calls will only be made when the document has fully loaded:

$(document).ready(function(){
 // enter code here, will be executed immediately after page has been loaded
}); 

By combining these 2 we could now set your dropdown's onchange event to the following

$(document).ready(function(){
 $("input[title='DISPLAYNAMEOFFIELD']").change(function() 
 {
      //do something to other field here 
 });
}); 

The points that both Janis and Alex make are good ones. Here are a few of my own:

1. The "class" analogy that Janis draws is a good one. Content types aren't just data -- they're the behavior that goes with that data. This "behavior portability" enables us to stop thinking of SharePoint data as simply sitting in a list. Being list-bound is particularly constraining; content types break that constraint.

2. Content types are hierarchical in nature and support inheritance (as Janis alluded to). You can create as complex a hierarchy as you like, much like a class hierarchy. Content types deeper in the hierachy inherit fields and most code-related elements from higher in the inheritance chain. You can choose to keep parent behavior in a derived type or override it.

3. Something I particularly like about content types (related to behavior portability) is the ability to specify custom forms for viewing and working with data. I'm not talking about FormTemplates which plug into list form pages; I'm talking about a craft-your-own experience. The entire "list-centric" mindset of SharePoint can be turned upside down through well-crafted forms that are tied in via FormUrl elements specified in a content type's XmlDocument structure. A blank ASPX page becomes your canvas if you want it.

At the end of the day, I guess it comes down to this (for me): I can think about data being bound to a list and that list's behavior, or I can think about data being more OOP-like in nature with content types. Microsoft has made a heavy investment in content types within the SharePoint platform, and they've made strong arguments for their use in the information architecture of any site. Choosing not to use them could yield some surprises down the road.

Here's one just as an example: the MOSS Records Center. The "guts" of the MOSS Records Center leverages content types as a routing and sorting mechanism to simplify life (http://blogs.msdn.com/recman/archive/2006/09/12/750034.aspx). If you've got a lot of data without content type classifications and you elect to leverage a Records Center ... ouch.

Here's another example: search. With a well-defined information architecture based on content types, partitioning search scopes can become much easier since content type can be converted to a managed property almost effortlessly. With my current client, we do this to easily identify and categorize content for automatic scope inclusion.

Extreme example: publishing sites. You can't even leverage publishing site features without the use of content types, because all publishing layouts are tied to a content type in order to align list data with layout placeholders.

I could go on, but hopefully this gives you an idea of what content types can do for you both as both a developer and an admin. You certainly don't need to use them, but they do represent quite an improvement over the list-specific data days of WSSv2/SPS 2003.

For what it's worth!