"broadcast" was replaced with more specific multicast methods. All-station-broadcast would become a huge mess given the available size of IPv6 LANs -- imagine thousands of nodes broadcasting ARPs looking for each other. (it falls apart in IPv4 already) Multicast Neighbor Discovery limits who hears the requests and answers, in a network with multicast aware hardware.
And there are specific link-local addresses to speak to everyone on the link in the same manner as IPv4 broadcast, without using globally routable addresses.
Background
I am somewhere that blocks Dropbox downloads, so I can't see the captured traffic, but I'll go on the assumption these were 64-byte ethernet multicasts.
Let's do some math to see how much traffic you're permitting...
A 64-byte frame is 672 bits (including 8 bytes for Preamble/SFD, and 12 bytes for IFG)...
8*(8 + 12 + 64) = 672 bits
That means line rate Gigabit Ethernet 64-bytes frames is about 1.488Mpps...
(1000000000 / 672.0) = 1488095.24 pps
What does this mean to you? Well your current storm-control configuration throttles traffic at 5% of line-rate, so you're allowing 74.4kpps of traffic to hit your switch before storm-control kicks in. 74.4kpps * 64-byte frames is 38Mbps, which is right at what your graphs show:
Answer
So, the bottom line is that you're allowing too much traffic to hit the switch CPU, which is why the CPU utilization was high. 74.4kpps is really too much to allow any switch CPU to process.
Assuming these stations shouldn't be sending a lot of multicast or broadast, the simple answer is to throttle your traffic like this...
! Note that broadcast traffic has the ethernet I/G bit set
! which means it is also classified technically as a multicast
! for storm-control purposes. Therefore set your broadcast limit
! a little lower than your multicast limit
storm-control broadcast level 0.4 0.3
storm-control multicast level 0.5 0.3
Now storm-control kicks in when a port sends 6kpps of broadcast (0.4% 1GE line rate) or 7.5kpps of combined multicast / broadcast (0.5% 1GE line rate).
FYI, it is probably worth looking into Control Plane Policing, which protects the switch CPU against several ports ganging up on it. Keep in mind that CPP can be complicated to get right, so it's a good idea to test well before you roll it out in your environment.
Best Answer
Node-local scope is mostly useful for inter-process communication. The sender and receiver can be different processes on the same node.