Is there a way to stop 'child exited with status 1' error when running st -e 'curl wttr.in/LOCATION | less -R'?

I'm trying to get a script to open a new st terminal window and execute curl -s wttr.in/LOCATION | less -R.

st -e "curl wttr.in/LOCATION | less -R" opens the terminal window briefly, but closes and returns child exited with status 1 in the parent window.
I don't want to have to make a command in /local/bin just to make that request.
Is there a better way?

Background

Well-designed terminal programs take argument vectors that can be invoked directly with execve() (or the newer posix_spawn() family of syscalls), not shell commands for invocation with system(). This makes them easier to use securely, avoiding the need to quote and escape contents to be passed as arguments into a single shell command (where without that escaping one is vulnerable to injection attacks). Some legacy terminals take system()-ready sh strings (at least for compatibility), but you're using software from https://suckless.org/ -- they've taken it on themselves to do better.

The Short/Simple/Insecure(?) Fix

The terminal you're using takes a command and argument list after -e as separate arguments. Therefore, you want something like:

st -e sh -c 'curl wttr.in/LOCATION | less -R'

Here, sh is the command to run in the terminal, -c is its first argument, and curl wttr.in/LOCATION | less -R is its second argument.

Doing This Securely

If your location is coming from a variable, however, then you should keep it out-of-band from the content passed as a script:

location="wttr.in/LOCATION"
st -e sh -c 'curl "$1" | less -R' sh "$location"

Here, your script curl "$1" | less -R is run with a $0 of sh (used in error messages to describe the name of the program that failed; change it however you like) and a $1 of wttr.in/LOCATION. Passing the URL in $1 means that a URL containing a string like $(rm -rf ~) won't delete your home directory, as it might with less incautious approaches.