First, let's just clarify that JSLink is not equivalent to Client Side Rendering. JSLink is merely a property on SP objects that lets you attach Javascript files to them.
However, the ability to attach a Javascript file to a SP object is enormously useful for CSR. Using the JSLink property is one of the easiest ways to apply CSR.
And I would say that since CSR is the way SP itself renders things, and MS has exposed this mechanism and enabled you to use it to override the default rendering, then CSR is the "formal" way to do things like hiding columns.
In your particular case, using JSLink/CSR could be very useful. You say you want the fields to "never appear" in new/edit forms. The SPField object has a JSLink property, so you can attach some CSR code to each field. Then the code travels with the field wherever it goes, meaning, even if your users create a new custom content type with one or more of those fields, your rendering overrides will still be applied.
This would mean that you would have to break up that code into one file for each field. The CSR code for one of the fields would look something like this:
(function () {
var overrideCtx = {};
overrideCtx.Templates = {};
overrideCtx.Templates.Fields = {
// need to use the internal name of the field here
"ItemNumber": {
"NewForm": formFieldOverride,
"EditForm": formFieldOverride
}
};
SPClientTemplates.TemplateManager.RegisterTemplateOverrides(overrideCtx);
})();
function formFieldOverride(ctx) {
// get the span that represents the field's actual edit control
var span = $get(ctx.FormUniqueId + ctx.FormContext.listAttributes.Id + ctx.CurrentFieldSchema.Name);
// still need to go up two levels to hide the entire <tr>
span.parentNode.parentNode.setAttribute("style", "display:none");
return "";
}
That being said, I see you have fields listed like "Recurrence" and "All Day Event", which look suspiciously like default SP calendar event fields. I don't think you'd want to attach a CSR file to one of those fields that hides it in the new/edit forms, because who knows, you might want to set up a calendar some day that allows you to have recurring or all day events...
For more information on CSR in general I recommend these two articles:
Client Side Rendering: List Views
Client Side Rendering: List Forms
Also, here is an article that describes how to hide fields in forms using basically the same jQuery technique you used, but applying the jQuery through JSLink/CSR rather than running the code on $(document).ready().
To answer your questions from your comments:
You asked what is the "formal" way to do these kinds of things, and I'm just arguing that because SP itself uses CSR as the way it renders things, then using the same mechanism to override the default behavior could be considered the "formal" approach. That does not mean using jQuery in a Script Editor web part to manipulate a page is "bad practice", in fact it is a very common practice, and I use it too, depending on what I am trying to accomplish.
You just have to think about what it is you are trying to do. If you stay with what you have already, the custom rendering you are doing (hiding the fields) will only apply to that page where you have added the script. If that's enough, then you're fine. But, if you want the custom rendering to be more widespread, then there are other ways to accomplish that, so you don't have to go and add a script editor web part to every page where you want the fields hidden.
Think about it: if you want a field to be hidden on every single new/edit form, no matter what, then every time a user makes a new list and adds that field, you are going to have to know about it and go and add a Script Editor web part to that form page, and add your script. That's a lot of work. Unless... you use JSLink to attach a CSR script to the field itself. And yes, it will apply to everywhere the field is used if you attach it at the proper place. If you have a custom field defined as a site column in the root site of a site collection, and you attach the CSR script at that level, then it will apply to anywhere that field is used throughout the site collection. However, if you have added the field to a list, and you attach the script to the list level copy of the field, it will only apply to that list.
Similarly, if you have a custom content type that uses that field, and you want your custom rendering to happen only when that content type is used, but you don't care if the custom rendering is applied if someone uses the field outside of that content type, you could create a CSR script that applies to the field, but attach it to the content type. And again, if you do this at the site collection level, it will travel with the content type and will apply anywhere it is used in the site collection.
So there's really a lot of options and a lot of possible behaviors, you just have to figure out what exactly is the behavior that you want to see, and figure out the best approach to get that. Like I said, if all you care about is hiding the fields for the new/edit form for that one list, and you have it working already with the Script Editor web part, then you're done. If you did want to change it to a CSR script, and still only have it apply to that one list, then you can do it easily because the List Form web part has a JSLink property (you can see it in the "Miscellaneous" section if you edit the web part).
As far as how to set the JSLink property and attach CSR scripts to fields and content types, take a look at this article that shows examples of how to do it through server side code (if that's an option for you) or Powershell.
