PHP Notices are good to avoid, but won't harm the system or functionality of this plugin. They can be annoying if you log Notices in order to update a site or remove deprecated code ... but until WordPress and the plugin repo have better test coverage, preventing Notices all the time may remain a personal preference.
What you're doing isn't harmful, although it does create another potential Notice case:
In the event that this plugin is enabled but the admin hasn't set 'memcache.default_port' then a new Notice will occur when your ini_get() is run. This is unlikely, but if you're going to open a door you may as well go all the way. To prevent that case you'll want to add something before that $buckets = line, which will test if 'memcache.default_port' is set and create a default port if not.
On the general idea of preventing Notices:
There is code in WP core devs that does this: 'if ( $var ) ...' which doesn't prevent Notices like 'if ( ! isset( $var ) ) ...' My personal preference is isset(), but that's because I think it's more readable.
The WP code conventions don't note a preference in preventing Notices. Because I'm overthinking this already, I think it's worth putting effort into isset() so your code if more clear: http://make.wordpress.org/core/handbook/coding-standards/#clever-code
There's some dispute about the performance of testing for existence. That could be with older versions of PHP, or due to redundant, duplicate tests. With modern PHP I think there's not a significant performance impact: http://www.brandonchecketts.com/archives/php-performance-isset-versus-empty-versus-php-notices. And on big server clusters that aggregate logs, I think preventing Notices would end up being more performant.