What's the maximum actual bit rate of an 802.11g connection?

With strong signal, no noise, a client and AP that both do frame bursting, and a well-optimized app (actually a throughput test tool called IPerf) I've seen 802.11g TCP throughput of barely 30 megabits/sec.

In real world conditions I'm happy as long as it's over 15 megabits/sec.

The rule of thumb for 802.11 is that you can get TCP throughput of 50-60% of the signalling rate you're getting, and you only get the best signaling rate under the best conditions.

Update: Just realized I didn't answer some of your subordinate questions.

Is 23 megabits/sec the best you can do (assuming no frame bursting)? Yes as I recall, somewhere between 20 and 25 megabits/sec is about the best throughput you can expect out of 802.11g without frame bursting.

Are there things you can tweak to get better performance? Yes, here are some things you can tweak to get better performance. However, I'll warn you up front that some of them are probably more hassle than they're worth:

1. Make sure you're on the cleanest channel available to you. The only way to do this reliably is to use a spectrum analyzer such as a Wi-Spy. Some people think they can get away with using something that only sees Wi-Fi networks like inSSIDer, but they're wrong. There can be a lot of noise in the 2.4GHz band that doesn't come from Wi-Fi gear, so inSSIDer would never see it, but a real Wi-Spy (or an even fancier spectrum analyzer) would.

   1b. If your gear is not just b/g but actually a/b/g, see if any of the 5GHz channels available to you are cleaner than any of the 2.4GHz channels, and if so, consider switching to 802.11a in 5GHz.

2. If your equipment supports frame bursting but you haven't turned it on, you can turn it on. Different vendors may have different ways to described frame bursting, such as "turbo mode" or something. If I recall correctly, Broadcom branded frame bursting, plus some other tweaky proprietary performance optimizations, as "Afterburner". Beware that some of these things can cause interoperability problems, and tend to work best between chipsets from the same vendor, from the same era.

3. If you have control over what tools/protocols you use to do your downloads, including the server side, then you can choose things that make more efficient use of TCP. For example, a good quality FTP or HTTP server is more likely to "keep the pipe filled" by constantly streaming the file using rolling buffers to make sure the sending-side TCP stack is never starved for data to send. In contrast, remote filesystem protocols like SMB and AFP tend to do individual reads and writes in blocks, so between blocks, TCP doesn't have anything to send. This can make a big difference over the course of a large download.

   3b. Again if you own both ends of the file transfer, you can look at TCP tuning. For example, make sure your client and server (especially the receiving end of the file transfer) is using an adequate TCP Window Size. TCP tuning is beyond the scope of this Answer, but if you Google for it and learn about things like bandwidth-delay products and optimum window sizes and delayed Ack and disabling Nagle's algorithm and using sysctl's (Unix / Linux / Mac OS X) and I guess registry editing (Windows) to adjust those things, you might find ways to squeeze a little extra performance out of your link.

   3c. Again if you own both endpoints of the file transfer, you could choose a high-performance UDP-based fast file transfer app. These apps are usually proprietary and require you to have the same app on both ends of the connection. Whereas TCP is very good at going as fast as it can without making Internet congestion worse, some of these UDP-based apps take the selfish approach of optimizing your file transfer speed without concern for the effect they have on network congestion.

Overall, if you've got a 40+ megabit/sec Internet connection, then 802.11g from 2003, which isn't any faster than 802.11a from 2002, isn't the right solution for you. Time to get some 802.11n equipment and party like it's 2007. Or some 3-spacial-stream 802.11n equipment and party like it's 2010.