First of all let’s say that regarding these functions what is valid for styles is exactly valid for scripts, but there are some exceptions to the contrary explained in the answer.
Main difference between wp_enqueue_* and respective wp_register_* functions, is that the first adds scripts/styles to the queue, the second prepares scripts/styles to be added.
You probably already know that, but there is a second difference; wp_register_* can be used in every hook, even in an early hook like init, but wp_enqueue_* should be used on wp_enqueue_scripts hook (or admin_enqueue_scripts for backend) 1.
The typical scenario of using both functions is when you want to register scripts/styles on theme init, and then enqueue them conditionally on some pages, e.g.
add_action('init', 'my_register_styles');
function my_register_styles() {
wp_register_style( 'style1', get_template_directory_uri() . '/style1.css' );
wp_register_style( 'style2', get_template_directory_uri() . '/style2.css' );
wp_register_style( 'style3', get_template_directory_uri() . '/style3.css' );
}
add_action( 'wp_enqueue_scripts', 'my_enqueue_styles' );
function my_enqueue_styles() {
if ( is_front_page() ) {
wp_enqueue_style( 'style3' );
} elseif ( is_page_template( 'special.php' ) ) {
wp_enqueue_style( 'style1' );
wp_enqueue_style( 'style2' );
} else {
wp_enqueue_style( 'style1' );
}
}
In this way the conditional enqueuing is more readable and less verbose.
In addition, if you want to enqueue one or more of the registered styles/scripts also in the backend, you can use the registered handle in a function hooking admin_enqueue_scripts without having to pass all params again.
Sure this is more useful for scripts, because of wp_localize_script that in previous scenario can be called once, after script registration, and then on conditional enqueuing just enqueue the script, even if it is used more than once: this keeps code simpler and DRY.
When you register a script/style and immediately after you enqueue it, it’s just an unnecessary task, that actually can be completely avoided:
wp_register_style( 'style1', get_template_directory_uri() . '/style1.css' );
wp_enqueue_style( 'style1' );
There’s no advantage to enqueuing a style (or script) in like this, just use wp_enqueue_style with all params of wp_enqueue_style and you are done.
Previous sentence is also true regarding the child theme friendship. To overwrite a style in the child theme, when the parent is using wp_register_style immediately followed by wp_enqueue_style, you have to de-register the style and register again with another URL. If the parent is only using wp_enqueue_style, in the child theme you can use wp_dequeue_style and enqueue the new style, so in the child theme you need 2 lines of code in both cases.
However, what is very child theme friendly is to wrap the functions that enqueue and/or register styles and scripts in a if ( ! function_exists( … in this way child theme can overwrite parent theme styles and scripts all in one place:
if ( ! function_exists( 'my_register_styles' ) ) {
function my_register_styles() {
wp_register_style( 'style1', get_template_directory_uri() . '/style1.css' );
wp_register_style( 'style2', get_template_directory_uri() . '/style2.css' );
wp_register_style( 'style3', get_template_directory_uri() . '/style3.css' );
}
}
if ( ! function_exists( 'my_enqueue_styles ') ) {
function my_enqueue_styles() {
if ( is_front_page() ) {
wp_enqueue_style( 'style3' );
} elseif ( is_page_template( 'special.php' ) ) {
wp_enqueue_style( 'style1' );
wp_enqueue_style( 'style2' );
} else {
wp_enqueue_style( 'style1' );
}
}
}
Now in the child theme it’s possible to write another my_register_styles and/or my_enqueue_styles function and change all styles (if needed, of course) without having to deregister/dequeue styles one by one.
1 Here’s another difference from scripts and styles: wp_enqueue_script can be used in the body of a page (typical use is in a shortcode) and the script will be put in the footer.