The controller is a Microchip LAN9512 and the reason it is used instead of, e.g., a bunch of independent controllers is presumably:
Price. Here's an example of somewhere you can buy 100 of them @ $5 each.
Form factor. You may remember the Raspberry Pi being marketed or tech blogged about as "a credit card sized computer" or "a computer which fits in the palm of your hand", not, "yet another mini-ITX system", or "a computer that will fit under a large hat", etc.
Power. Glancing at the first page of the data sheet (accessible through the Microchip link) "implements reduced power operating modes" is mentioned as one of the "Features". You'd have to dig deeper to find out what that really means in comparative terms but, on the surface at least, it makes conceivable sense.
Remember, the pi cost ~$35 retail. Not $135 or $350. So that's the answer to the literal question in your title, "Why do the USB ports and Ethernet port share the same controller?".
Note it's not an unusual approach for multiple USB ports to share the same bus --- it is probably the norm. I notice the laptop I'm on now has 3 USB ports but
lsusb reports only two, 2.0 "Full speed" hubs. So at least two of those ports share a hub and they will not both get "Full speed" at the same time. I'm sure if you check your current system it's put together along similar lines.
Combining the ethernet with that is unusual, but it's worth noting that USB 2.0 should provide 480 Mbps whereas the 10/100 ethernet connection would require at most 100 of those.
Wikipedia notes, citing spec as a source, that, "Due to bus access constraints, the effective throughput of the High Speed signaling rate is limited to 280 Mbit/s or 35 MB/s"; whether that means per port or for the bus as a whole is unclear.
to what effect is data transfer slowed down
Obviously you won't get more than 480 Mbps total, and you probably won't get more than 280. Personally, I've never seen or heard reports of a pi doing better than 10 MB/s transfer from local ethernet to a USB drive (i.e., 80 Mbps) consistently for normal purposes. However, that number is after the protocols themselves have been handled, which will add a variable but I think small percentage -- with ethernet it may vary greatly depending on the topology and activity of the connected network.
is there a workaround to this problem
If you mean, can I squeeze more water through a pipe than the pipe was made to contain then no, or can I get a pump to work faster or some combination or the two again, no. If you need a faster pump or a bigger pipe, buy a faster pump and a bigger pipe.