Like so:

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?

Speed.

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.