I'm not sure I follow you. Do you mean that the routing systems at the lower networking layers can be thought of as proxies in the sense that they copy data in and copy data out? That's technically correct, but they're not conventionally called proxies.
Proxies, by definition, are intermediaries. Everything on the internet is connected by a giant network of proxies at some layer - NATs, gateways, firewalls, etc.
Kubernetes runs a cluster of machines that act like a mini internet, with many containers running many apps. These apps communicate with each other across containers and machines through a series of proxies so that apps only have to worry about a single address or service name. Kubernetes does allow for headless services which will publish all of the pod IPs under a DNS name if you want but this is usually not the common scenario.
Beyond just knowing endpoints, apps may need to worry about healthchecking, failover, load balancing, rate limiting, security, observability, routing decisions and more. It's far simpler to consolidate all this functionality rather than leaving it to every single app to implement it all over again.
An ingress controller is in charge of running a specific proxy that deals with traffic into and out of the cluster rather than within it. There are several implementations other than nginx and they all require various levels of tuning to fit the needs of the cluster, but it's an optimal solution since you might not want or have access to control traffic on the other side.
