¿Cuándo deberías usar WP_Query vs query_posts() vs get_posts()?

query_posts - Nunca deberías usar query_posts. Además de lo que @Rarst ha mencionado, el gran problema con query_posts es que rompe el objeto de consulta principal (almacenado en $wp_query). Muchos plugins y código personalizado dependen del objeto de consulta principal, por lo que romperlo significa que estás afectando la funcionalidad de plugins y código personalizado. Una de estas funciones es la importante función de paginación, así que si rompes la consulta principal, rompes la paginación.

Para demostrar lo malo que es query_posts, en cualquier plantilla, haz lo siguiente y compara los resultados:

var_dump( $wp_query );
query_posts( '&posts_per_page=-1' );
var_dump( $wp_query );

get_posts y WP_Query son la forma correcta de construir consultas secundarias (como publicaciones relacionadas, sliders, contenido destacado y contenido en páginas de inicio estáticas). Cabe destacar que no deberías usar ninguno de los dos en lugar de la consulta principal en la página de inicio, página individual o cualquier tipo de página de archivo, ya que romperá la funcionalidad de la página. Si necesitas modificar la consulta principal, usa pre_get_posts para hacerlo, no una consulta personalizada. (ACTUALIZACIÓN: Para páginas de inicio estáticas y páginas verdaderas, consulta Usando pre_get_posts en páginas verdaderas y páginas de inicio estáticas*)

En esencia, WP_Query es utilizado por la consulta principal y también por get_posts, pero aunque get_posts() usa WP_Query, hay algunas diferencias:

• get_posts es más rápido que WP_Query. El margen depende de la cantidad total de publicaciones del sitio. La razón es que get_posts pasa 'no_found_rows' => true por defecto a WP_Query, lo que omite/legalmente rompe la paginación. Con 'no_found_rows' => true, WP_Query obtiene la cantidad de publicaciones consultadas y luego se detiene, mientras que, por defecto, sigue buscando todas las publicaciones que coincidan con la consulta para calcular la paginación.

  Por esta razón, get_posts() debería usarse solo para consultas no paginadas. Paginar get_posts es realmente un gran desastre. WP_Query debería usarse para todas las consultas paginadas.

• get_posts() no se ve influenciado por los filtros posts_*, mientras que WP_Query sí. La razón es que get_posts, por defecto, pasa 'suppress_filters' => true a WP_Query.

• get_posts tiene algunos parámetros adicionales como include, exclude, numberposts y category. Estos parámetros se convierten en parámetros válidos para WP_Query antes de ser pasados. include se convierte en post__in, exclude en post__not_in, category en cat y numberposts en posts_per_page. Solo una nota, todos los parámetros que se pueden pasar a WP_Query funcionan con get_posts, puedes ignorar y no usar los parámetros predeterminados de get_posts.

• get_posts devuelve solo la propiedad $posts de WP_Query, mientras que WP_Query devuelve el objeto completo. Este objeto es bastante útil cuando se trata de condicionales, paginación y otra información útil que se puede usar dentro del bucle.

• get_posts no usa el bucle, sino un bucle foreach para mostrar las publicaciones. Además, no hay etiquetas de plantilla disponibles por defecto. Se debe usar setup_postdata( $post ) para que las etiquetas de plantilla estén disponibles. WP_Query usa el bucle y las etiquetas de plantilla están disponibles por defecto.

• get_posts pasa 'ignore_sticky_posts' => 1 a WP_Query, por lo que get_posts ignora las publicaciones fijas por defecto.

En base a lo anterior, decidir si usar get_posts o WP_Query depende de ti y de lo que realmente necesites de la consulta. Lo anterior debería guiarte en tu elección.

La diferencia básica es que query_posts() realmente solo sirve para modificar el Loop actual. Una vez que hayas terminado, es necesario restablecer el loop y dejarlo seguir su curso. Este método también es un poco más fácil de entender, simplemente porque tu "consulta" es básicamente una cadena de URL que pasas a la función, así:

query_posts('meta_key=color&meta_value=blue'); 

Por otro lado, WP_Query es más una herramienta de propósito general, y se parece más a escribir consultas MySQL directamente que query_posts(). También puedes usarlo en cualquier lugar (no solo en el Loop) y no interfiere con ninguna consulta de publicaciones que se esté ejecutando actualmente.

Por lo general, tiendo a usar WP_Query con más frecuencia. En realidad, todo dependerá de tu caso específico.

Simplemente no hay necesidad de usar query_posts(). Todo lo que hace es instanciar un nuevo objeto WP_Query y reasignar ese nuevo objeto a global wp_query.

Como referencia, lo siguiente es la función real query_posts().

function query_posts($query) {
        $GLOBALS['wp_query'] = new WP_Query();
        return $GLOBALS['wp_query']->query($query);
    }

Instancia tu propio objeto WP_Query si deseas crear un script de consulta personalizado en profundidad. O usa get_posts() si solo necesitas hacer algunas manipulaciones menores aquí y allá.

En cualquier caso, recomiendo encarecidamente que te hagas un favor y vayas a wp_includes/query.php y examines la clase WP_Query.

Asegúrate de usar wp_reset_query() después de usar query_posts() porque afectará también otros resultados de consulta.

Si recuerdo bien lo que leí, básicamente "el loop" está haciendo WP_Query en los archivos principales, pero de una manera más fácil de entender.

• query_posts(): podría usarse en un único caso si necesitas modificar la consulta principal. Establece muchas variables globales;
• get_posts(): es muy similar en mecánica y acepta los mismos argumentos, pero devuelve un array de posts
• WP_Query: puedes crear y trabajar con tu propio objeto de esta clase. Un poco más complejo, con menos restricciones, es seguro usarlo en cualquier lugar.