There are a couple of things to note:
1. You cant set the user's Growl preferences from within your application. So when you register your application or send a notification, you can specify some properties (like stickiness) which will be used *if the user has not specifically chosen to override them*. What your app sends are only for that specific request - only the user can set their preferences via the Growl UI. That is by design - the user is always in control of how the notifications are handled.
2. Although you can send a custom binary property and name is "Sound", Growl doesnt know that you intended to associate that with the 'Sound' preference (which you cant set from your app anyway - see #1). Just because it is named 'Sound' doesnt make it associated with the sound preference.
Custom properties (be they text or binary) are normally used for custom displays, forwarders, subscribers, or other plugins. When they have additional knowledge about the custom properties, they may choose to act differently. For example, the iRate display is mainly designed to work with iTunes notifications (though it can be used with all other apps as well). As such, it looks for custom properties that the iTunes Growl Plugin sends (ex: song rating information) and can display a star rating UI element if it finds them. (It can also use custom properties in the other direction to send additional information back to the application).
If the end goal is for notifications from your app to make a sound, then you have a couple of options:
1. The end user can use Growl's preferences to select the sound they want to hear when the notifications from your app arrive, or
2. The end user can choose a display that makes a sound and associate it with your app/notifications