When I see two interfaces covering the same network/netmask combination, I expect there to be a different route “metric” (basically a marker of hop count or hop cost which is reflected in TTL) tied to each interface. An attempt to reach an address over both otherwise sufficient interfaces will pick the interface with the lowest metric. If one of the interfaces goes down, then the remaining interface will get the traffic (with the lower metric interface gone, the higher metric becomes the lowest metric).
Bonding two interfaces together (link aggregation) to act in parallel would mean equal metric, and require support at both origin and destination with some sort of virtual device to split traffic of a single connection between both interfaces (likely you would get a new virtual device and not talk to eth0 or wlan0 directly…it would be the virtual device doing the talking to eth0 and wlan0 and the routing tables). For example, if you need higher bandwidth and only DSL is available, you could get two DSL lines and you and your ISP could configure for aggregation…but the key is that simltaneous use via aggregation requires support at two points in the network, failover via metric does not. I do not believe that normally wlan0 and eth0 can bond for higher throughput without a third virtual interface at both ends of the connection.
Normally if a connection uniquely matches a combination of network and netmask, then that interface will be chosen. Normally no two interfaces will have the same network and netmask combination. If a connection is not directly served by a specific network and netmask combination, then the default route will be used under the assumption that the routing at the next hop can find a suitable interface, or find another router, and eventually find a suitable interface. So order of using an interface would be lowest metric of a specific network/netmask, followed by a default route.
For reference, your default route has metric 0 and aims at wlan0; wlan0 has metric 9, and eth0 has metric 1.
In your case, both wlan0 and eth0 are the same network/netmask (which I think is invalid if you want to use both at once), so only the one which has the lowest metric (eth0) will ever be used on something going to a 192.168.0.0/255.255.255.0 combination. Yanking the eth0 cable and having the kernel detect a route failure would cause the same connections to then try to go over wlan0 (the next highest metric of a specific network/netmask match).
Your default route would be used if you are trying to reach an address outside of the 192.168.0.0/255.255.255.0 combination. This specifically means it’ll try to talk to the router at the other end of the WiFi (default route is wlan0). I’m not sure how it may change things, but also notice that your default route has the lowest metric (highest priority if two routes can handle the same thing).
As an experiment, you could temporarily delete the default route, and then add it back:
sudo route delete default
#...when done testing:
sudo route add default gw 192.168.0.1
#...observe if default route now uses eth0...this would be good.
…since eth0 is now the highest priority (lowest metric) I hope it would become the interface used for any 192.168.0.0/255.255.255.0 connection, or via default route (we just removed default and added it back in at a moment when eth0 has the lower metric). Without the default route, connections to any other network/netmask should fail. Had default route been assigned with eth0 as its interface to 192.168.0.1, then eth0 would work regardless of wlan0 status. Removing and adding the default route back in could change the interface to eth0, this would be one of the goals of the experiment. Perhaps if default route was assigned while bringing up interfaces such that wlan0 was there and eth0 was not yet configured, then this would explain the reason why the higher metric wlan0 was previously picked as default instead of eth0.
A big question is whether the things you are trying to network to are all in the 192.168.0.0/255.255.255.0 address space? If not, is 192.168.0.1 able to forward everything? Is the 192.168.0.1 router accessible via WiFi?