If the parent theme isn't using wp_enqueue_script, it's probably hooking into wp_head (or wp_footer) to echo out the scripts there. So you'd use remove_action to get rid of those functions echoing the scripts out, and then enqueue your own script.

If the script is hard coded into the template file, you'll just need to replace that template file in your child theme without the script tag.

If they used wp_enqueue_script calls that utilize get_stylesheet_directory_uri, then you shouldn't have to do anything. Since this isn't happening, you'll just have to poke around and see what the theme author did.

if the parent theme uses get_stylesheet_directory_uri to enqueue scripts, then the child theme will have to duplicate all scripts thus enqueued, because otherwise they woun't be found. There is no fallback mechanism in get_stylesheet_directory_uri to check if an individual file exists in the child theme and fall back to the parent theme's file if necessary.
– user18579Jul 26 '12 at 13:20

Keep in mind when this was written: two years ago. Before wp_enqueue_scripts could be used to only enqueue scripts on the front end. Updated. If you see something out of date, feel free to edit.
– chrisguitarguyAug 13 '13 at 15:02

Update for 2016: according to stackoverflow.com/questions/23507179/… we also have to use wp_deregister_script('parent-script-handle'); to completely remove the parent script. Indeed, it didn't work for me without it. WP 4.6.1
– PhiLhoNov 30 '16 at 9:58

In this case, wp_enqueue_scripts was called by the parent with a priority of 20120206 (the date) and so this action is added with a priority just barely greater so that it will immediately be dequeued. Then, the enqueue statement that follows that follows is actually prioritized after that to ensure that it loads after the old one was dequeued. The true, in this case is also important because that specifies that it is to be enqueued in the footer, which is where the parent script was first enqueued.

Also, I can't quite explain it entirely, but I notice that if you are careful with dequeuing the initial script immediately after it being enqueued, it seems you can effectively prevent it from loading in the first place.

The function wp_enqueue_script doesn't have a priority parameter, it's only a version number which is concatenated to the end of the path as a query string. This parameter is used to ensure that the correct version is sent to the client regardless of caching [...]
– Emile BergeronJan 18 '16 at 14:51

Why? This is only needed when you are using the same handle – something you don't have to do. You probably even shouldn't, because it is easier to debug code whose source is clear.
– fuxia♦Dec 25 '16 at 18:14