There are 2 bugs when the 'Enable external blogs' (useexternalblogs) config is disabled, which together mean that users are able to publish from external blogs, regardless of the value set on useexternalblogs.
Firstly, it appears that the only thing disabling that option does, is remove the link to {wwwroot}/blog/external_blogs.php from the user's preferences page. However, visiting that link (or {wwwroot}/blog/external_blog_edit.php) directly still allows access. Secondly, if any external blogs are registered for the user, they will always appear in the blog, regardless of the useexternalblogs value.
I think 2 fixes are required:
Most importantly, if external blogs are disabled, do not include those posts in users' blogs. Currently, this behaviour also means if an admin has enabled external blogs, but later disables it, it will have no effect on any blogs that were previously set up to pull in external content (it will need to be considered whether that is intended functionality).
Secondly, the behaviour of the external blogs registration page should be made consistent with the link on the user preferences page. I would suggest that the link should be reinstated on the user's preferences page, since it would enable users to remove existing feeds if they no longer want to refer to them (in case external blogs are ever re-enabled in future), along with a warning on the external_blogs.php and external_blog_edit.php pages that they can be added/removed, but are disabled and won't be visible within the blog. The other option would be to leave the preferences page as-is and just set up a redirect on the external_blogs.php and/or /blog/external_blog_edit.php pages so they're inaccessible, though I think it's better for users to be able to remove any external blogs they have set.
Note: I have not set a security level on this, as I don't think users are able to publish anything they wouldn't be able to otherwise manually publish to their blog (for example, scripts are stripped from external entries just as they are on internal ones).
(Issue based on Zendesk report 27327 from Benjamin Böck)