Istio's deployment requirements state that a Pod must belong to at least one Kubernetes Service in order to form part of an Istio mesh. One of the reasons for this as I understand it is to create an entry to refer to the Pod (or group of Pods) in configuration rules (e.g. <serviceName>.<namespace>.svc.cluster.local).
Are there any other reasons?
Many of Istio's features (policy enforcement, distributed tracing, cross-service metrics) depend on knowing what service a request is coming from. Ordinarily you only need to create Kubernetes services to route inbound requests to specific pods, but Istio uses them more generally to associate pods with abstract "services".
Say pod A is calling pod B. Even in plain Kubernetes you need a service for B, and the request from A would target the service rather than the pod directly. If you set up, for example, metrics in Istio (maybe using its built-in Prometheus), then Istio also tries to look up a service for A. If it finds it then you'll see metrics like istio_requests_total(source_service="A", destination_service="B"). If it doesn't the source will just show up as "unknown".