Whether and how something should be escaped is largely dependent on where the data came from and how it will be used. It’s primary function is to prevent data from being interpreted as a part of the code or mechanism which the data will be contained in – we don’t want a value used in a URL’s querystring containing &s to be interpreted as additional parameters, for instance. Or data which will be inserted into an HTML attribute to contain quotations that would effectively enable it to potentially close the attribute quotation and have it’s contents interpreted as markup.
In this case where you’re embedding the value in a JS string, all we can say for sure is that if the value has any chance of containing a ", we want to escape those quotations such that the data could not execute arbitrary JavaScript. WordPress’s esc_js() may be a good escaping selection here.
When possible, it is recommended that you transfer data from PHP to JS using a wp_add_inline_script() call. We can mimic the functionality of wp_localize_script() by json_encoding() an associative array of data into a JSON object (which might not be necessary if you only have one/a few values, or the script for which you’re inlining data depends on specific globals/variables):
function wpse408964_enqueue_scripts() {
$result = //...;
wp_enqueue_script( 'my-static-script', plugins_url( 'js/static.js', __FILE__ ) );
wp_add_inline_script(
'my-static-script',
'const MYDATA = ' . json_encode( array(
'sel' => esc_js( $result[0] )
) ),
'before'
);
}
However, this may not be possible depending on your specific use-case.