Presuming that prepared queries are easy to use and don't cause performance issues here, then you should just use prepared queries. All else being equal, I prefer to do things the secure way by default. In other words, instead of asking "Should I do this the secure way?" (which is what you are asking) try approaching from the opposite perspective: "Is there any reason not to do this the secure way?". Unless you have a good reason to do it without prepared queries, just always use them.
For session variables I think it is especially important to always use prepared queries, because their nature makes it easy to lose track of where they came from. It is true that given your current use case there is no immediate risk of an SQL injection vulnerability (but note that session data and cookie data can be easily confused, and the latter are not secure). However business needs often change and this can generate a large risk when the creation of data is not easily "visible" from where it is used. What happens if on the next iteration of the application one of these pieces of data now comes from user input? You'll probably remember to convert your query into a prepared query when you first store the user input. But will you remember to follow that same data through your entire application and make sure you aren't using it without prepared queries in a later place? If you end up inserting the data into the database securely, but later fetch that data from the database and use it in another insecure query, then you can still end up with an SQL injection vulnerability.
So don't ask "Should I use prepared queries?". Instead start from the other end: "Is there a reason why I shouldn't use prepared queries?". If you don't have a compelling reason to skip the prepared queries, then use them. If you think you have a good reason to do it insecurely, then at least you are at a good starting point for a thorough cost/benefit analysis.
Prepared queries with variable column names
Please note that this syntax is not actually allowed for prepared queries:
$editSQL = "UPDATE myTable SET ? = ?, ? = ?, ? = ? WHERE ID = ?"
Column names cannot be provided with place holders. As a result you actually can't build prepared queries like this. Instead you have to provide the column names as variables into the query building, which means that it can be vulnerable to SQLi vulnerabilities. Therefore, the way you protect against SQLi in cases like this is by whitelisting the variable contents to make sure that it is exactly something that it is supposed to be.