As a point of further clarification, Apache is the soul user and manager (assuming it is the only thing listening on port 80) of the http(s) protocol requests being delivered to the server, As such it manages all requests to other system resources on behalf of the preprocessor, in this case WordPress in the form of PHP.   As such WordPress and by extension PHP have no ownership on the system, they/it (PHP) passes the requests to Apache which does have a user on the this system.  So in the context of WordPress, Drupal, Laravel ... [insert php framework here], when it comes to the user it is ALWAYS Apache.  In The 2 major packaged builds of Apache in commercial use are Debian with user:group www-data, and RHEL which is apache:apache respectively.

You should only be looking for www-data or apache depending on your system.  Grep-ing for wordpress or some other name is a waste of time because I doubt you went in and altered Apache to use a different name ... cuz who would want that insanity. 

When it comes to ownership and permission management of the file system that is always the OS.  While it is common to see the boiler plate apache ownership in the file system:
Version 1 (CentOS)

$ ls -la 
drwx-r-xr--x   1 apache apache 2034 Jun 27 04:43 wp-content (for a dir)
-rw-r-xr--x  1 apache apache 2034 Jun 27 04:43 objectcache.php 

you are just as likely to see this on a production server:
Version 2 (CentOS)
$ ls - la

drwx-r-xr--x   1 hosting hosting 2034 Jun 27 04:43 wp-content (for a dir)
-rw-r-xr--x  1 hosting hosting 2034 Jun 27 04:43 objectcache.php 

Both of these permission and ownership versions of the same file/folder combo will return the same with the ps command
$ ps -ef | egrep '(apache|httpd|www-data)'
root      2492     1  0 Jun27 ?        00:00:01 /usr/sbin/httpd -DFOREGROUND
apache    2636  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    2638  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    2644  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    2645  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    2648  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

Both versions work and both versions are valid. The difference is that in Version 2 Apache does not have write privileges to the files.  So Why would you do that?  Because unless your application needs to have Apache write to files it is a security risk to do so.  Some PHP applications (Drupal) require apache to have write privileges but only to a certain directory. While WordPress does have proprietary plugins that require write privileges they are usually only needed during an upgrade or initial installation of the plugin.  This is the biggest use case by far for WordPress needing write privileges.  In this scenario we use a CICD pipeline application to temporarily change the permissions so Apache can write and then reset the restrictions once deployment and installation are complete.  If the site needs constant write privileges we usually recommend switching to Drupal or another framework that has more robust security.  If by some unfortunate circumstance we have to use WordPress and have to give it continuous write privileges we point the requirement to a folder (typically a separate file share) and try and lock down Apache with as much write limitations in the <directory> directive in the Apache conf file for the site as possible. 

We usually also do not setup SFTP in production.  Again that is what a CICD workflow is for and that is usually done from a build agent (jenkins/bamboo server) that has password-less SSH access and/or OAuth support.  Hosting companies do provide SFTP access to site accounts but it is usually dynamically instantiated at the time of the request and destroyed upon exit.

Hope the helps or maybe it was just already understood.