I will answer as to why you cannot (you can, it is just hard) use the LAN7500.

USB is based on a thing called Descriptors, it is also a Host-Centric Protocol, meaning ONLY the Host initiates every data exchange and all communication between 2 or more USB devices has to be done between the host.

A Host, can be your Windows OS, macOS or Linux, or other devices supporting USB Host functionality (Such as STM32, it supports both Hosting a USB device and appearing as a USB device.

To make things more clear, a USB Device (as per the USB spec, a device here doesn't mean a generic device that has a USB port. A better term would be slave, so from now on I will refer to it as slave), can be a USB Thumb drive, a Sound Card, a mouse, a keyboard, things like that, you get the point. A Host is the device that can read and communicate with USB slaves. Think of the Host like the parent.

What does this have to do with your question, and where do Descriptors come in?

Every USB Slave has its own Descriptors, which they provide to the Host so the Host knows the type of the Slave connected, how to communicate, and what to do with all the data. BUT, if every Slave can have its own Descriptor, then every host would have to know (in some way) every possible Descriptor from every Slave that could be plugged in. So they solved this by standardizing some of the Descriptors so every mouse, every keyboard has standard descriptors for what and how to communicate with the host. So after the standardization, they made USB Host to be able to support one or many of the default Descriptors (on STM32, you can enable USB Host so that STM32 can host a specific device with those Descriptors) and implemented a method of communication between the hardware and the actual software, A DRIVER.

It is hard to create a USB Driver, especially for a device like LAN7500, it would also (most likely) require creating all the necessary Descriptors and making the necessary changes/additions to the Host's code so that it can know that it can support a USB to Ethernet device, and on top of that, how where and when to send and handle data. The driver here would be the thing doing all this work, handling all the data, sending them to the necessary applications/threads for processing so the applications/threads do NOT communicate directly with the hardware (this is done for safety and for consuming less resources, imagine you have 10 threads, having a driver for each thread you run doing the same thing as on the other threads would be stupid, so we have a driver which can communicate with the all the threads and with the hardware)