If your product is designed for technical-users, it's likely that most of them have already migrated to Leopard, making the headache of ensuring support for Tiger likely not worth it.
If your product is designed for non-technical users, the headache of remaining backwards-compatible is probably worth it based on the vast number of folks who don't upgrade until they buy a new computer with a new OS pre-installed.
That said, if you really can't advance your current version while remaining backwards-compatible, then why not fork the product and make the Tiger version a little bit cheaper? I've seen that from other developers, and absolutely love them for it.
Joel Spolsky says it best here: http://www.joelonsoftware.com/items/2007/09/18.html.
"The developers who ignored performance and blasted ahead adding cool features to their applications will, in the long run, have better applications."
Do not accept what your customers want now as your future goal. That now will be history when you ship.
Listen with caution to your existing customers that either don't or haven't yet purchased the flagship upgrade from the leading vendor in the market. They probably won't buy your stuff in any quantity, either.
Existing customers will almost never tell you they want to buy an upgrade.
There are other potential schemes - such as parallel product release streams for 10.4 Tiger and for 10.5 Leopard - though these should be approached with caution and particularly with an eye toward the added expenses that will be incurred. These tend to be feasible in larger software products, when there are established revenue streams and customer bases and with the requisite source code management skills and tools present.
The DL dev's justification is that almost all the people who spend money on software will buy Apple's stuff first, thus being Leopard-only cuts out only a small amount of your market.
TextMate's dev justified it in a similar way, saying that 90% of his customers are early-adopters who would be on Leopard as soon as it came out.
It is interesting to note that both of these apps have niche markets (people who organise their media collections and programmers/geeks). Thus, the devs are probably confident in their predictions about not reducing their potential customers too much.
If it's something that pivots entirely around a feature in Leopard, like Time Machine integration, then go for Leopard only. Otherwise, release for both Tiger and Leopard. Why not? Not everyone is using Leopard yet -- I read somewhere that the adoption so far is about half Leopard and half pre-Leopard. I'm not sure how accurate that is, but I have a hard time believing it's true.
I only updated to Leopard on my main workstation about a week ago.
At an established software company, this is a very easy question to answer - you just look at the user agent stats on your purchase page.
But the developers tell me that Leopard offers a lot of animations and stuff (CoreSomethingSomething? haha) that Tiger does not do.
But development for Leopard is also nicer because you can now use Objective-C 2.0 and garbage collection and lots of other new classes, like e.g. NSOperation which helps development for multi-core processing.
..if you're just relying on Core Animation for a few animations, you can write those yourself. And if you're not going to use Obj-C 2.0 GC for performance reasons, strike that off.
You can easily put Leopard-specific features/hacks in, too. I developed ShoveBox for Tiger, but I've had to add in some logic around how the app works with Spaces.
...but if, by the time you're done, the target audience of your app will have already gotten Leopard, it might be useful to just target it. There are a lot of useful enhancements all around the API that will save you time.