Continuing the discussion from Change the name of the Uncategorized category:
The other petition is for changing the name of the default category (“Uncategorized”).
I wouldn’t be surprised if this requirement is difficult to remove…
My proposal: remove the requirement that Posts need a category.
More perspective: most sites I build do not use Categories, but do use a lot of custom taxonomies. Categories are always this hanging taxonomy that I have to take steps to “hiding” it from the UI.
Other times, the “default” category is chosen, causing additional editorial work to fix metadata.
Overall, for me, the Category requirement has always been clunky and an extra step (along with turning off comments, tuning off avatars, etc…). 
What would this look like?
The built-in functions to handle categories used to be unique, and over the years have evolved to use the generic taxonomy and term functions. Do all of those functions handle the non-existent case?
Would the permalink functions that handle the %category% need to have a fallback for no category?
Do the template functions that show the categories need to change to not put the label if there are no terms?
What else?
In the sites I’ve built, I manually change the name of Uncategorized to something more useful. Usually News, though I suppose it could just as well be unpublished to remind me to finish them up and change the category.
As for removing categories all together, I wouldn’t like it. Instead of supplemental taxonomies, I’ve mostly used categories. Categories allow me to cross reference between content types by using the same taxonomy.
This petition is not for the removal of categories; it makes it so you don’t need to set a default category, similar to how tags or a custom taxonomy works.
1 Down Vote for this suggestion.
Reason: Custom Post Type will almost always use taxonomies and so having the WP base category terms and term-meta being disturbed—in any manner—is very much a “nontraditional” aspect of what a Blogging platform DOES. (Even IF you do not use it as a blog.) And could also make some plugins and themes NOT backwards compatible.
But I do understand the concept and maybe a premium CP theme could handle this. (Oh boy, just what the world needs: More Premium Themes. LOL)
Hi! 
Thanks for the feedback. Could you clarify that quoted sentence for me? I don’t understand the use of “nontraditional”, but I’m simple, so if you use simple words I’m sure I’ll get it!
Would you mind qualifying that statement? In my experience, we don’t use the default taxonomies with CPTs we develop. But I’m one person! Maybe we have some way to know how folks use CPTs and which taxonomies they are configured to use?
I should have already said: these are great questions, and I’ve been considering them. I hadn’t considered them before making the suggestion, so I’m doing my homework. When I have some ideas for moving forward, or more likely more questions, I’ll let everyone know.
In general any taxonomy can share meta values, including custom fields in regular post, and there may be some terms that get saved as meta-terms but not as post meta data. So without having some default categories it is hard to make queries if a regular post_type is looking for a taxonomy term that has not been registered correctly and core (default) will have nothing to fallback on if there is not a relationshi[p. It will return (and CAN) return false but that may not complete the query.
In short, why mess with the core taxonomies when they are needed for almost all searches and organization of posts.
Just to understand you are saying that not wanting to assign a category (given that the category is there) can’t be done?
What I mean is treating a post like a page, while still having the category list.
And selecting which post get assigned to a category and which not.