I am also facing the same issue. My Jenkin Master is linux and slave is Windows Server 2012

I ran into similar issue and it was struggling to run "pwsh" on mac slave. I think iti s related to "PATH" environment variable.  "pwsh" was installed into "/usr/local/bin" but the "PATH" had only "/usr/bin:/bin:/usr/sbin:/sbin:" You can try to run a build step e.g. 
sh "/usr/local/bin/pwsh -Command \"Get-Host | Select-Object Version\""
just to make sure you can run powershell using the full path to the executable. I ended up with modifying slave configuration to have PATH variable have "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin". Note that thier fancy syntax PATH+EXTRA did not work so I just added PATH with all paths I needed.

This is not an issue only when using jenkins in a slave machine. In my master machine I have the same exact issue and the problem is clearly that the PATH variable doesn't include /usr/local/bin directory for the spawned daemon that run jenkins. Setting PATH+EXTRA as kkutsner mentioned can't be a solution because the environment variable is modified too late and that settings doesn't influence resolving of shells location.

If installed jenkins with homebrew, one workaround is to edit ~/Library/LaunchAgents/homebrew.mxcl.jenkins-lts.plist to specify a full list of paths like the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>EnvironmentVariables</key>
    <dict>
       <key>PATH</key>
       <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
    <key>Label</key>
    <string>homebrew.mxcl.jenkins-lts</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/libexec/java_home</string>
      <string>-v</string>
      <string>1.8</string>
      <string>--exec</string>
      <string>java</string>
      <string>-Dmail.smtp.starttls.enable=true</string>
      <string>-jar</string>
      <string>/usr/local/opt/jenkins-lts/libexec/jenkins.war</string>
      <string>--httpListenAddress=127.0.0.1</string>
      <string>--httpPort=8080</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

Then you can restart the service or the machine.

The pipeline plugin could indeed also be improved so it attempts to resolve location fo pwsh with more fallbacks. For example it could (on unix platforms) try to find with this order:
1) Result of /usr/bin/env pwsh
2) Result of which pwsh
3) Direct path /usr/local/bin/pwsh if existing
4) Direct path /usr/bin/pwsh if existing

Of course the result can be cached so this resolution is not repeated everytime a pwsh directive is used.

It's 2024, and the issue hit me again on MacOs slaves, so I'm the identical situation of the original poster but with a more recent version of Jenkins installed in the master (2.426.3). The issue again is with the setting of the PATH variable, which is early set within a non-interactive login in the slave machine and not altered to include the /usr/locan/bin path where pwsh resides, as it can be seen in the following log:

SSHLauncher{host='host', port=9513, credentialsId='mac_agent', jvmOptions='', javaPath='', prefixStartSlaveCmd=' ', suffixStartSlaveCmd='', launchTimeoutSeconds=60, maxNumRetries=10, retryWaitTime=15, sshHostKeyVerificationStrategy=hudson.plugins.sshslaves.verifiers.ManuallyTrustedKeyVerificationStrategy, tcpNoDelay=true, trackCredentials=true}
[02/14/24 09:37:03] [SSH] Opening SSH connection to host:9513.
...
PATH=/usr/bin:/bin:/usr/sbin:/sbin

A clean workaround is setting the Prefix Start agent Command to something that will alter PATH, like the following:

export PATH="/usr/local/bin:$PATH" &&

similarly to what described in the troubleshooting guide for ssh agents, so that in the end the agent will be started with the correct environment and a line like the following one will appear in the log then the agent is starting:

[02/14/24 09:37:06] [SSH] Starting agent process: export PATH=/usr/local/bin:${PATH} && cd "/Users/user/remoting" && java -jar remoting.jar -workDir /Users/user/remoting -jar-cache /Users/euronovate/remoting/jarCache

The issue has been open for a long time, and the problem is clearly present, even if it affects only the few people that uses Jenkins on Macos and powershell for scripting. A solution in Jenkins may explore why pipeline pwsh directives can't use PATH+EXTRA configuration, or fix it straightly by hardcoding more search paths for pwsh in Unix operating systems.