If you don't have a setup like Mgotts' where the wireless NIC is disabled when the wired NIC is connected, or a convenient way (airplane switch) to disable the wireless NIC manually, some operating systems may refuse to accept the address on the second NIC if they do an ARP check to ensure the IP is available and reply to themselves (there seem to be some cases where Windows XP confuses itself in this way).
There is another disadvantage of the same-IP setup for both wireless and wired NICs (if you don't explicitly manage things so that only one NIC is active at a time). When other systems ARP for the IP, they can get replies from both the wireless and wired NICs. In that case, it is a toss-up which MAC address they will select (and the odds may be in favor of the slower one that comes in second). As a result, even if you set up your routing to prefer the faster wired NIC (easiest to do on MacOS X, but possible on other systems too) the return traffic from other systems may be sent to your wireless NIC anyhow. And if you do manage things so that only one NIC is active at a time, you may experience a "glitch" for a few seconds when you switch over, while other systems still have the other MAC address in their ARP tables.
(Speaking of managing the two NICs so that only one is active - there is a MacOS X Hints posting with several versions of a script for doing this entirely automatically.)
One of the biggest advantage of the same-IP setup is that existing TCP or VPN connections will keep working even after you switch from one interface to the other. If you are just doing web stuff this may not matter so much, since in the different-IP setup your browser will recreate connections transparently (and on the web server side, it won't even see an IP change if your firewall NATs both to the same external IP). But if you use a VPN or SSH connections, not having to re-establish those connections is very convenient.
The trickiest part of configuring the same-IP setup may be getting your DHCP server to accept it; at least some versions of DD-WRT don't allow it, and DNSmasq DHCP servers require you to do it in a particular way - from personal experience I can say that OpenWRT will let you set it up, but then the DNSmasq DNS/DHCP server won't start. A related ServerFault question discusses what you need to do to make it work for Windows 2003 DHCP server. As noted there, it may be necessary to force the same MAC address on the two NICs (depending on the hardware and OS, you may need to clone the wireless MAC onto the wired NIC).
Using the same MAC address for both NICs may also be useful to mitigate the "glitch" mentioned above due to stale ARP table entries on other systems, and allows you to get the same-IP setup even if you don't have control of the DHCP server (e.g. at your workplace). There is some precedent for setting the same MAC on all the NICs of a system - old DEC systems did this, and Sun/Solaris systems may still. There are some gotchas about doing this, which is probably why most systems don't do this.
If your wireless AP or switches have implemented port security options, you may find the MAC blocked out on one or the other NIC, and in a large bridged network with multiple switches, the "glitch" for connections with a system that is distant may be worse unless your laptop is actively sending traffic (broadcast or multicast traffic will do) through all intermediate switches so that they update their forwarding tables and traffic to the shared MAC address goes to the currently active NIC.
Using the same MAC address for both NICs may also be necessary to get the same IP address if you are using IPv6, which generally doesn't use DHCP, but embeds the MAC address in the low 64-bits (host part) of the IPv6 address.