When using WP_DEBUG the following errors are displayed in the admin plugins page:

Notice: Undefined index: PO_group_view in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 481
Notice: Undefined index: PO_group_view in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 497
Notice: Undefined index: PO_group_view in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 566
Notice: Undefined index: plugin_status in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 398
Notice: Undefined offset: 0 in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 381

Using WP_DEBUG during plugin development is a best practice as you can see here:

Undefined indexes are not errors. They are a notice. You should never have those turned on in production and I'm well aware that they are there. The undefined index may pose a problem however. I will look into that.

Technically speaking you are correct. Some (all?) of those warning probably do not result in a but. The concern however is that you are not using WP_DEBUG so you might be missing warnings that actually matter.

Here's other issues: people who develop sites with WP_DEBUG cannot use your plugin without it throwing errors, so besides being annoying while development when demoing to clients they ask "Why is it broken?". And some of the more advanced people in the WordPress community actually prefer to run their sites with WP_DEBUG being true.

Here's what Andrew Nacin the development lead for WordPress 3.5 has to say about WP_DEBUG[1]:

If you’re a plugin or theme developer and you don’t know what the WP_DEBUG is, you’re missing out. (If you do know what it is and you don’t use it during development, you’re crazy.)
...
In a nutshell, there’s an entire API devoted to informing you of the best practices and the latest APIs.

So, it's pretty easy to fix these, just always use WP_DEBUG when you are developing and then you'll be able to see and fix these issues.

If you run your site with wp_debug set to true you are opening yourself up to hackers. That level of error reporting should never be turned on in a production site. It should only be turned on for testing. I do turn my error reporting up during development but undefined indexes are not problems. They are sometimes intended. As is the case with the notices you reference. I could put an array_key_exists in the if statements to get rid of them but since they are not necessary and can become very redundant I generally don't use them.

When you turn on WP_DEBUG you are essentially turning on error_reporting and setting E_ALL. This can have the effect of server path disclosure to a hacker. You have also done the same thing above by pasting your server path for everyone to see. This is not a good idea.

Path disclosure doesn't make a site vulnerable. Yes, it's information that could make it a little easier for a determined hacker to find things to poke. But only if you server has a vulnerability in the first place. Security through obscurity is not security, as the saying goes. Also, the path Mike posted above is obviously on his own local dev setup, and most-likely not on a public-facing IP.

That said, eliminating all warnings and info messages is still a Best Practice. Yes, it's annoying to error-check every instance of an array index, define(), etc. But it's still a Best Practice. Clean code is happy code!

Oh, and nobody is advocating running with WP_DEBUG in production. But even so -- many sites turn on logging for warnings or even info messages. If you leave in code that generates these unneeded messages, all those servers running your plugin will waste CPU cycles and disk space for them. I, for one, get annoyed when my logs are polluted like that.

Here's a write up on OWASP of the problems that arise from full path disclosure. I'm not advocating security through obscurity but there are many different steps one needs to go through to achieve a secure platform. Hiding this vulnerability is one of them. WordPress is known for its security holes and there is no reason for leaving this one open. He was advocating for running with WP_DEBUG set to true in production.

Im not trying to be defensive. I'm just trying to point out that notices are not errors and that they should be ignored. There are many more areas of this plugin that throw notices and I have yet to find a plugin that doesn't give some kind of notice. The suggestion has been made before and I am well aware of the notices. The plugin is working as intended.

He was advocating for running with WP_DEBUG set to true in production.

Not sure how you got that impression. My initial post said (bold added):

Using WP_DEBUG during plugin development is a best practice

My only mention of using during production was this aside only because you should never have those turned on in production, which wasn't the point:

And some of the more advanced people in the WordPress community actually prefer to run their sites with WP_DEBUG being true.

Again, I wasn't trying to make you defensive. If you think it's acceptable to leave notices in your plugin then given current requirements of the plugin repository it's your prerogative. I'm now sorry that I ever brought this up.

WP_DEBUG is indeed often run in production (including on wordpress.org itself). But it is best to not conflate the two things it does. Primarily, it sets error reporting to include notices — that's the important part. While it also forces errors to be displayed, that isn't something you'd do in production — that's why this part is overridable (via WP_DEBUG_DISPLAY).

The important thing isn't displaying errors, it's recognizing that notices are errors. They often indicate (as you mentioned) a problem, or an assumption that could result in a problem later.

To double @Nacin and add some further explanation: Without WP_DEBUG, you're not able to use WP_DEBUG_LOG. And you'll really want to use this in production too, as you might not know what happened to your site, when your server starts crashing. Log files can be accessed even after your site is long gone.

As an addition, here's a short sneak peek from my local config setup. "Error level: Paranoia".

In case you're wondering why I'm doing this, here's the explanation. If you ignore Notices, Warnings or errors, then you're making the life of everyone who is coding after you pretty hard. If you deliver code that other people build upon, extend, etc. then you're responsible to throw no errors/warnings/notices at all, because else no one would be able to distinguish between their own errors and yours.

I wouldn't use WP_DEBUG_LOG in production, unless you've specifically blocked wp-content/debug.log from external access. (I wished we didn't introduce that to begin with, and I don't know how long it has for this world.) Rather, you'll want to use standard PHP error logging.

Fine. I will go through the plugin and remove notices. But please take my advice. It is not a good idea to run with that level of error reporting on in a production site. Unless you don't get much traffic. If the notices are printed to the screen it can give a hacker clues as to how your system is set up. Plus it has to write every one of those notices to a file and can bring down your server. Believe me I've seen it happen. Best practice is to only log critical errors to your log unless it is a dev server. You can try your best but I can still create notices in your error logs to fill it up by playing around with ajax requests and other URL's.