Ultimately, iptables chain design is a mix of personal preference and utilization of functionality. I come it the exact opposite way as you, for example. I love the iptables "metaphor" and abhor the Cisco ACL metaphor. I like to think about stateful conversations rather than packet flows. (If I have to choose between a Cisco PIX or router w/ the firewall feature-set versus iptables, in terms of pleasure to administer, I'd take iptables any day...)
The phrase "I will probably end up using stateful inspection..." is a bit confusing. Netfilter is a stateful packet filter. You could write a ruleset that works around its "statefulness", but that would be counter productive. Writing rules based on the establishment of connections is also a lot more pleasurable, I've found, than trying to write the necessary rules and "mirror" rules to manage traffic statelessly.
You want a packet to traverse as few chains as possible, and as few rules as possible. Starting your "filter" table chains with -m state --state RELATED,ESTABLISHED -j ACCEPT will allow the stateful inspection engine to push packets for already-established connections thru the rule set without traversing the entire chain.
What you're proposing with the interface-related chains will work just fine, and it's a fairly common practice. If you have a common set of rules that need to apply to every interface I'd put them in the common chain first, then branch to other interface-specific or traffic-type-specific chains from there.
