To help to understand these concepts I would differentiate first the Spring specific functionality from that exposed from Java.
PropertyEditors and the related stuff are defined by the JavaBeans Specification.
The specification defines an API, mechanisms and conventions for dealing with objects, objects properties, and everything related to their changes, as events.
PropertyEditors are typically used in GUIs to handle the interaction between an UI and the underlying objects model, typically handling the conversion between properties values from/to its String representation.
Spring itself actually uses different PropertyEditor implementations and Java Beans conventions in many different situations. For example, from the docs:
A couple of examples where property editing is used in Spring:
Setting properties on beans is done by using PropertyEditor
implementations. When you use String as the value of a property of some
bean that you declare in an XML file, Spring (if the setter of the
corresponding property has a Class parameter) uses ClassEditor to try
to resolve the parameter to a Class object.
Parsing HTTP request parameters in Spring’s MVC framework is done by
using all kinds of PropertyEditor implementations that you can manually
bind in all subclasses of the CommandController.
In summary, PropertyEditors allow you for a broader number of use cases.
Now, in the Spring world you need to do a differentiation as well between Spring MVC and Spring Core.
Please, note that both the Convert and the Formatter stuff are defined as core technologies, of relevance to any use case and not limited to the web framework.
The Spring documentation, when describing Spring Field Formatting, provides a great explanation about the purpose of every API/SPI and how they are related to PropertyEditors as well:
As discussed in the previous section, core.convert is a general-purpose
type conversion system. It provides a unified ConversionService API as
well as a strongly typed Converter SPI for implementing conversion logic
from one type to another. A Spring container uses this system to bind bean
property values. In addition, both the Spring Expression Language (SpEL)
and DataBinder use this system to bind field values. For example, when
SpEL needs to coerce a Short to a Long to complete an
expression.setValue(Object bean, Object value) attempt, the core.convert
system performs the coercion.
Now consider the type conversion requirements of a typical client
environment, such as a web or desktop application. In such environments,
you typically convert from String to support the client postback process,
as well as back to String to support the view rendering process. In
addition, you often need to localize String values. The more general
core.convert Converter SPI does not address such formatting requirements
directly. To directly address them, Spring 3 introduced a convenient
Formatter SPI that provides a simple and robust alternative to
PropertyEditor implementations for client environments.
In general, you can use the Converter SPI when you need to implement
general-purpose type conversion logic — for example, for converting between
a java.util.Date and a Long. You can use the Formatter SPI when you
work in a client environment (such as a web application) and need to parse
and print localized field values. The ConversionService provides a
unified type conversion API for both SPIs.
In the specific use case of Spring MVC the framework itself is able to handle simple types when handling the HTTP requests.
Type conversion is automatically applied based on the configured set of converters, although that behavior can be tweaked using DataBinders and the aforementioned Formatting system. Please, see the relevant docs.
In a typical use case in which you deal with reading and writing the body of HTTP requests and responses, when using the @RequestBody, for example, Spring will use a bunch of different pre-configured HttpMessageConverter implementations: the actual ones registered will depend on your configuration and the libraries imported in your project - say Jackson, for example. I was unable to find that point in the documentation but here is the link to the actual source code.
Please, consider review this related SO question, it could be of help.
