Add class name to DOM element
However, I feel it's long-winded.

To reduce the amount of repeated code, and to make it easier to adapt for different columns without writing the same sort of thing again 2 or 3 times, look for similarities across the different columns. For every column, you're calling arcapi.dataResult().columnNameToIndex, so you can make a function which, given a column name, calls that. You're also accessing the this.children[index].innerHTML for every index retrieved.
One option is to use objects instead of multiple standalone variables. You can have an object indexed by variable names, whose values are the column indicies. Then, in the selectAll callback, you can construct an object with the same properties but with the text values you're interested in by using mapping the object's entries and passing into Object.fromEntries:
function rm_row() {
  const getIndex = columnName =&gt; arcapi.dataResult().columnNameToIndex(columnName);
  const columnIndiciesByName = {
    inherent: getIndex('Inherent Risk'),
    residual: getIndex('Residual Risk'),
    perf: getIndex(arcapi.getSetting('Column name')),
  };

  d3.selectAll(&quot;#&quot; + arcapi.chartId() + &quot; .dataTables_scrollBody tbody tr&quot;).classed('removerow', function() {
    const columnTextsByName = Object.fromEntries(
      Object.entries(columnIndicies).map(
        ([key, columnIndex]) =&gt; ([key, this.children[columnIndex].innerHTML])
      )
    );
    columnTextsByName.perf = columnTextsByName.perf.replace(/[`~%]/gi, '');
    // Then refer to columnTextsByName.inherent, etc

The above is just an option to consider. While this makes the code less repetitive and more flexible for future added or removed columns you might want to check, I'm not entirely convinced that it's a solid improvement over your current code if you're not expecting your current code to change. YMMV; you may consider your current code to be more readable, or not.
Other possible improvements:
Don't use var in ES6: If you're going to write in ES6 syntax - which you should, it's great - there's no reason to use var, it has too many gotchas (such as function-scope hoisting and automatically being assigned to the global object on the top level) to be worth using. Always use const (or, when you must reassign the variable, let).
JS naming conventions The vast majority of professional JavaScript uses camelCase for functions and ordinary variables. snake_case is quite rare (and mixing snake case with camelCase in the same variable name is even weirder). Consider using camelCase everywhere that it's appropriate.
cf_regex On a similar note, name your variables appropriately: in your original code, cf_regex is not a regular expression, it's just a string which has had certain characters replaced. Better to call it something more accurate and longer (I don't have any idea what it's meant to be, and neither will other readers of the code given only this context)
Something odd about the regex - you're using the case-insensitive flag i, but you're not matching any letters, so the flag isn't doing anything. Might as well remove it. Or, to make it clearer what's going on, if you're expecting the result to contain only numbers, match digits instead:
columnTextsByName.perf = Number(columnTextsByName.perf.match(/\d+/)[0]);

(since you're going to be comparing with numbers later, it feels better to cast the variable being compared to a number too; it makes more sense and will make debugging a bit easier if problems arise later)
innerHTML or textContent? Unless you're deliberately retrieving HTML markup, which doesn't look present here, if you just care about the text of a cell, it would be more appropriate to use .textContent rather than .innerHTML. It's faster too.
Semicolons You're using a few semicolons, but also missing a bunch. Unless you're an expert or use semicolons everywhere, you may eventually get tripped up by Automatic Semicolon Insertion. Consider using a linter.
Performance You say

I have thought of creating an array and store all my variables in an array, but I feel this approach will be expensive.

On modern computers, the overhead of creating an array or object instead of multiple standalone variables is completely nonexistent. If using a particular data structure makes the code more maintainable (given whatever style you prefer), go ahead and do it. If you later find that there's a performance issue, feel free to go back and debug to find what exactly the bottleneck is, so you can figure out a more efficient method - but using an object or array will almost certainly not be the bottleneck. Try to avoid premature optimization, or at least don't sacrifice code clarity for it unless you have to.