Yes..............................

Yes it will to some extent, but I don't think you will see the same kind
of performance  degradation that you would see trying to implement
security trimming of the page interface itself. The contents of the
list webpart will always be refreshed when the page postsback, so you
aren't really invalidating a page fragment. But the refreshment of that
list will take slightly more time than retrieving a list  that is not
individually permissioned.

Seriously, 50,000+ hits a day from 3,000+ unique visitors will tax
anything using AD Groups to determine real-time which of 200 individual
items to show. I'd conduct some benchmarks before proceeding with this
plan. I'd also plan for the likely scenario you will need to implement
some kind of caching. I also plan for the likely scenario you will need
to move the entire list  to a custom database table (a simple XREF table
will do) and query for the items for which a given user's groups have
access.

Can it be done, probably. Will it degrade performance, probably. Will
the performance  hit be crippling, I dunno? If you go this route, be sure
that you stress test it to death.

The reason I'm exploring this avenue is
that the current plan is to use Audiencies to achieve the same
functionality. My immediate feeling was that Audiencies shouldn't be
used for what is essentially security  trimming. I wonder if perhaps
Audiencies *and* item level security should be set but only the
Audience setting is used to filter the list  in the custom web part?
Perhaps I'll stress test this approach against straight item level
security and see how it fairs.

Your immediate feeling is correct. Audiences are used to filter content that
the user does not NEED to see. security  trimming, obviously, is used to block
access to items that the user CAN NOT see. If this is a security concern
(rather than a usability concern) audiences are probably not the way to go.