One sticking point I rarely see discussed with the prevailing line of thinking (noted by tptacek, patio11 and others), is that a week
is a measure of time.
If that's true, there is only time-based billing, and project-based billing. I've done both types, and project-based billing has been much more dangerous for me due to the need to accurately scope (or eat costs), usually for a client that has no idea how difficult "simple" additions can be (and often when you yourself cannot). Software scoping is effectively impossible to do accurately, and I've found the only way to get close is when you have already built the system in question before (or better yet, have a codebase you can reuse to hit 90% of the features in the first ~week of "work").
Hourly billing (whether you roll it up into a day/week/month) provides a way to cover myself from bad estimation, but limits you to charging for time to build and screws up incentives.
Project billing means I eat costs from bad estimation, but with the possibility of reward from over-estimation, along with the fact that you can charge for what the deliverable is worth (i.e. the value you deliver, not the time it took you to build the product).
As far as weeding out clients who aren't serious -- you can do that with a high-enough hourly billing (and generally you can get a feel for this from the client themselves)...
Could someone explain how I'm understanding the avoid-hourly-billing ideas wrong? It seems reasonable but it just doesn't seem to work for me in practice with the estimation thing, never mind the fact that clients need regular updates and rarely value good software development practices (so may seem like you've spent a week doing nothing if they can't immediately see the result/how it will save them time over the lifetime of the project).
[EDIT] - Another thing that I've realized when I was last thinking about this that I didn't include was that as complexity unfolded (and I realized my estimation was wrong), I did not increase prices/communicate this effectively to the business -- maybe that's where I'm getting it wrong? It feels like it would chip away at client trust to do so.
For those who are wondering what I actually do when I take projects on these days -- I just set a high hourly rate, possibly bundle it into weeks/months, and avoid project-based estimation because of the difficulty of scoping and the likelihood of scope changes. This also gives me an edge when the scope changes -- it's no longer "can this fit", and it's more "sure we can fit this in, it will take longer though".