Try looking at it from the Voice point of view. If possible we want to prevent the PC from seeing the Voice traffic. This prevents the PC from recording Voice calls illegally, the PC from having to deal with MOH broadcasts and allows you to make changes that effect only the Phones (DHCP, DNS and such).
It also gives Phones their own DHCP ranges for manageability, and allows you to monitor the traffic seperately based on vlan. You can then also restrict access to the Voice servers to the phone Vlans. QoS can be applied at the VLAN level as well.
I hope this helps.
I believe the security implications of VLANs are purely secondary to IP phones. The primary reason that it is recommended to put IP phones in their own VLAN is because of performance. You just don't want any significant number of phones and PCs on the same VLAN.
As for the rest, let me see if I can clarify it. When a Cisco IP phone connects to a Cisco switch that is configured with voice and data VLANs, the phone gets assigned the voice VLAN and the PC gets assigned the data VLAN, right? This means that the phone does not even see the broadcast that you mentioned from the PC, because it's not on the same VLAN! Yes, physically the broadcast passes through the phone, but because it is on a different network (for all intents and purposes), there is no impact on the phone. If you did not have this, then every time someone got a virus on their PC, the broadcasts would knock out all the phones.
If you have two switches connected with two cables you can force vlan-pc traffic down one cable and vlan-phone traffic down the other.
There is one more interesting thing in regards to this conversation that many don't realize. The Cisco Phones actually span traffic that is related to the voice side of the phone out the pc port. In other words, if you turn on Wireshark on a PC connected to the PC port of a Cisco Phone, you will see (and can listen to with G711) the voice traffic that is terminating on the phone. I don't think broadcasts are spanned though. In reality, the only broadcasts that I can think of that should see on the voice vlan is dhcp. In any case, this is an opposite scenario than what you seem concerned.
The other point is that the phones really don't see the the broadcasts from the PC vlan, they just pass them through. This is the point Clay made. The thing that is important to realize is that the Cisco Phone is 1) A Phone and 2). a 3 port switch. If you turn the phone over, you only see two ports. The third port is not physical, but what connects the phone's logic to the integrated switch.
Regarding security, all this helps. It is certainly nice to know what types of traffic are on each vlan. This certainly helps us group our like traffic together. Additionally, it can aid with IDS and filtering placement. However, it is worth noting since those VLANs are trunked down to the port in each office, that where there's a will there's a way. With Cisco switches there is a lot done with CDP, even sometimes trusting QoS based on the existence of a phone. There is no reason that a really persistent person cannot make a pc or laptop look like a phone, access the trunk, voice vlan and be part of the trusted QoS. All it takes is writing (or downloading) some code. In any case, this can make it more difficult (and obvious) when it happens
Hmmmm... I have to say I did not know that voice traffic leaked past the phone to the PC. Now... Why you would want to sniff your own phone's voice traffic is beyond me. Eavesdropping on yourself seems a little strange.
But on the other hand, it DOES provide a method to record your phone calls! Hmmmmmm.
Anyway, back to the original question.
The broadcasts will indeed hit the phone, but the phone doesn't have an IP in the data VLAN. So like any pure L2 switch, it will simply forward them.
When we complain about broadcasts, it isn't really the "packets" themselves that cause problems. It's that when they hit devices with an IP in that subnet then the rules are every station has to pause, unpack and act on the information. Switches just pass them. So no big deal. If your phone DID have an IP in the same VLAN, then they would have to unpack, look at and (most likely) discard the information.
But the CPUs on the phones aren't exactly incredible. So anything you are doing to distract the phone's behavior may degrade voice traffic processing.
I think there are ways that Cisco Desktop Administrator can take advantage of this with local call recording (as you suggested). I mostly use it for troubleshooting or understanding. You can see the signaling traffic (scp) and the RTP streams. Wireshark works better with SIP, but you can manually tag the RTP streams and listen to them. One end of the conversation comes through the left speaker and the other end comes through the right speaker. Pretty cool I think. Also, CAIN can listen to G729 which is a codec that I think is officially protected by some Digium agreement. I think Call Rex also has an implementation method that can use this feature. In any case, a properly positioned network SPAN port can get the calls as well, but this comes in handy and is something to be aware of. It can be disabled, but is enabled by default. Below is an attached image I pulled from Cisco's website on the CCM config.
Just use VOMIT to replay captured calls.
If you want to have a voip phone to have a voice vlan (voice) and have a passthrough with the phone to the pc with a different vlan (data). You will have to enable lldp which is Link Layer Discover Protocol, the command is LLDP run. Once that is enable configure Qos for the voice vlan. (it is opitional) On the port enable Switchport Access (Data vlan) and switchport voice (voice vlan). Now this switchport voice (voice vlan) command is on the up to date ios.