The question itself is actually flawed, since DIV is still with us and like SPAN has a very specific use and meaning -- or should I say lack of meaning.
Both DIV and SPAN are semantically neutral, they exist for the purpose of the application of style without saying what that style is. As such if you have written your existing HTML properly using the HTML 4 document structure, you can add/remove DIV with impunity without screwing that structure over. The thing is you should not e adding either of those tags until you have expended what can be done with your semantic tags, and/or as a way to group tags so that you can use one class/id to do the job of many; that way you aren't throwing endless pointless "classes for nothing" onto everything. This is why a lot of how people use DIV ends up much akin to Carlin's joke about abortion. Just as "not every ejaculation deserves a name" not every element needs a DIV, or two DIV, or twenty DIV around it!
... and that's where the new HTML 5 tags are a miserable failure. Their alleged meanings, uses, and purposes are in fact redundant to HTML 4 Strict. Worse, they disrupt semantics and logical document structure with rules over how things like SECTION and ARTICLE works.
Half the entire point of HTML 4 Strict was to simplify the specification and remove redundancies. Whilst HTML 5 does make some smart changes inside HEAD and overall in terms of removing more pointless garbage, it also ends up introducing more redundancies.
This is only further exacerbated by ignoring HTML 4 Stricts other reason for existing was the removal of presentation from the markup, something that many of HTML 5's tags -- like ASIDE -- exist for the sole purpose of, making it just as presentational in concept as CENTER or FONT.
Most of this stems from the fact that to be brutally frank, the people at the WhatWG that created HTML 5 didn't know enough about HTML to create its successor. By the admission of many people who worked on it this alleged "specification" was created more to document what people were doing a decade or more ago, instead of telling people how to do it properly. With most people of that time vomiting up HTML 3.2 under the guise of HTML 4 Tranny, is it any shock that HTML 5 flips the bird at everything 4 Strict was trying to accomplish?
You can see this in the stupid ignorant HGROUP tag they created -- that was removed from the spec almost instantly when the W3C shrugged their shoulders, said screw it, and adopted the WhatWG's BS as the new HTML -- where it basically created for the nonsensical pairing of headings, a common practice that is complete semantic gibberish since in most cases that second heading is not starting a new subsection of the page. The correct semantics would be SMALL inside the first heading for the subtext indicating de-emphasis.
But let's go down the list of problems.
SECTION. If numbered headings and horizontal rules mean the start of sections and subsections of the page, and do not mean fonts in different weights and sizes or drawing a line across the screen what possible reason do we have for even having a SECTION tag? It's a pointless redundancy that seems to have been created just to satiate the wants and needs of people who slop in endless pointless DIV for nothing; aka the same mindset that resulted in everyone slopping in endless pointless tables for nothing. That is completely screws logical document structure and alternative navigation by resetting you to H1 depth (or not, given the "it's not recommended but" caveat) really just flips the bird at users with accessibility needs.
ARTICLE. Given how people just throw this around randomly not even to mark articles, it seems kind of silly... but there is no grammatical / professional writing norm upon which to base ARTICLE for semantics. The main content of the page should suffice as the "article", and any summaries not being complete articles have no business in such a tag. It's pointless.
MAIN. If the first H2 or HR on the page is supposed to indicate the start of the main content of the page, as per professional writing norms, what possible purpose does MAIN serve other than a pointless redundancy?
ASIDE. If semantics are based on professional writing norms, there is no grammatical or syntactical reason to put things "off to one side". This leaves us with the literary concept of an aside; subtext running parallel to the main text that whilst related is optional. That semantic relationship is not what anyone seems to use it for, nor is it all that common a thing in writing unless you spend your life transcribing Shakespear or writing Ferris Bueller meets Deadpool slashfic. If you think this tag exists just to place some content "aside" or "off to one side" you know not the first blasted thing about semantics, document structure, or even the purpose of HTML since not all UA's or even all layouts will in fact place it to one side. Again, as pointless and stupid as the long dead CENTER tag!
HEADER. We have numbered headings. Why did we need another tag?
FOOTER. A meaningless distinction not one legitimate UA has any real reason to separate out, nor do they do anything meaningful with it.
NAV... its original WhatWG meaning of "The UA can skip this section to get to the MAIN content" is redundant to either the first H2 or even their own flipping MAIN tag. They newer meaning of "this contains links that can be used to create an accessibility menu" not one legitimate UA has implemented, and given the track record of implementing such things -- *like accesskey menus which only one engine (presto) ever did -- don't plan on seeing said tag actually being implemented any time soon.
Which brings us to the real nail in the coffin, the fact that not one legitimate UA is doing anything meaningful with them. In fact, it often seems that the only real reason these tags were created was much akin to the "microformats" rubbish that was all the rage a decade ago, where people were slopping ABBR title="" on everything just to waste bandwidth for normal users... and for what? To make data-scraper's lives easier.
Data scrapers, let's call a spade a spade, not a "gardening tool", and say what they really are, CONTENT THIEVES! Aka a group you usually don't want to make the life easier of!
Which is why pretty much every legitimate UA you would/should care about treats them as nothing more than generic block-level containers. Aka, DIV.
The same can be said for the ARIA role nonsense, more microformat junkie bandwidth wasting trash; labeling everything for non-semantic reasons; often redundantly; in a manner that just makes web development harder and does not one single blasted thing to improve accessibility. At least not compared to what HTML 4 Strict used properly and the content itself can/should be doing.
Again, you'd almost think the people who created HTML 5 and those singing the praises of these tags never actually embraced the concepts of semantics and HTML 4 Strict.
This get even uglier when we get into the tags and attributes that have zero business even existing, got shoved into the specification despite being redundant or bad practices.
Take EMBED, a tag rejected for 4 strict as redundant to OBJECT and being proprietary rubbish. Why the blue blazes is this in HTML 5?!? Or AUDIO and VIDEO which are also redundant to the purpose of OBJECT; non-text media. Did you know the original plan for HTML 4's successor at the W3C involved removing IMG for being redundant to OBJECT? I still support the idea. There isn't a single blasted thing done with IMG, EMBED, VIDEO, or AUDIO that couldn't be implemented on OBJECT. But no, they had to make the specification larger for no legitimate reason.
How about CANVAS? A tag that only exists as a hook for JavaScript... if it only exists for JS use, why the blue blazes does it even have a flipping tag? This would have been a lot more useful if the canvas' instance were/would/could be attached as a background or intermediate render layer to all elements. Mind you, I like CANVAS as a JavaScript feature, but since it's scripting only there is zero reason for it to have its own tag in the HTML specification. At best it too is redundant to OBJECT, at worst it's a "tag for nothing".
The return of MENU is also a confusing mess, given it was deprecated in 4 Strict and would have been a far better way of implementing what NAV is trying to do or at least what people seem to think NAV is for, but no... Instead it's got "something" to do with forms that I still can't get a clear explanation of exactly what that even is. MENU and DIR were deprecated as redundant to UL, leave them that way!
Then there are attributes like TARGET, which were stricken from non-frameset documents for being a miserable failure at accessibility and usability when people derp them into pages as "_blank". You don't go shoving new windows / tabs down the user's gullet breaking conventional navigation. That's why it was deprecated, and why the people who wanted their documents to validate and used JS to implement it completely missed the point, and why bringing it back for HTML 5 is mentally enfeebled nonsense! The user wants a new window/tab they can middle-click or CTRL-click. Don't whip that new tab/window out of your pants and go waving it in people's faces without so much as a "by your leave"! 99.99% of the time I see target="_blank" in a codebase, I automatically assume a mix of ... well, those two words I'm always overusing.
Hence why overall I consider most of the new tags that go into BODY from the HTML 5 spec to be steps backwards to the worst of HTML 3.2 style methodology and mindset. Much like the mentally enfeebled train wreck laundry lists of how not to build websites that are front-end frameworks, it's a step backwards to the browser wars era mentality of pissing on semantics in favor of using presentational markup. No matter how much they throw the words "semantics" at it. Such claims are nothing more than bald faced lies.
Mind you, it's not all rot. MARK is nice, MANIFEST is useful for app dev, the new INPUT types are really nice letting us kick a lot of "JS for nothing" to the curb, the removal of TYPE attributes on tags that shouldn't need them like SCRIPT or LINK when rel="stylesheet", and the greatly shrunk header area helps with bandwidth. Those are the things that make sense; but the rest of it? Not so much.
That's why a lot of developers -- as Dan W. pointed out -- will tell you to write for HTML 4 Strict, then deploy as HTML 5 for the handful of improvements, and the things being shoved down our gullets whether it makes sense or not like AUDIO and VIDEO.
I really think we need another HTML specification that is to HTML 5 as 4 Strict was to 4 Tranny. HTML 5 just feels like "the new transitional" in that in a lot of ways it's leaving the outdated 1990's development mindset in place to corrupt the minds of the current generation. I've been half tempted to sit down and do it myself. I do keep thinking "but who are you to do it?" -- but who was TBL in '87... who were the WhatWG? What makes the W3C the big authority on the subject other than de-facto lack of anyone else?