drush php-eval 'print_r(menu_execute_active_handler("node/8506"));'
Another example: load the user page as a different user ID:
drush -u 23 ev 'print_r(menu_execute_active_handler("user"));'
Why would I do this when debugging?
It's faster than things like the Masquerade module if you just need a quick page load to check something. You can pipe output to grep or do other sensible things, too, to hunt for unexpected results, e.g. | grep -A5 "<h1"
Direct access to errors.
You can see a PHP error written to stderr right in front of you. Sometimes it may be difficult/impossible to locate an error triggered via a browser or curl request, if the error happens early enough that it doesn't get logged beyond a 500 error in access.log.
I found a really obscure corruption in a Drupal watchdog table this way recently. Drupal was silently causing 500 errors I couldn't see in any other logs. Invoking the path this way revealed the PDOException that led to a solution. I've also seen PHP OOMs (exhausting the memory_limit) show up this way on sites that normally log those properly to an error file.
Isolate Drupal from the other request layers.
Drush works over php-cli. Making a request this way isolates the application from your web server, showing you just what Drupal is doing, rather than involving Apache and/or php-cgi or php-fpm, bypassing DNS or any of a bunch of other layers that could be messing you about.