No, you shouldn't be doing this and not just for minimal performance gains. I realize what made you think it'd be a good practice, but let's analyze these two quotes from the PHP manual a bit more:
session_start() creates a session or resumes the current one based
on a session identifier passed via a GET or POST request, or passed
via a cookie.
session_destroy() destroys all of the data associated with the
current session. It does not unset any of the global variables
associated with the session, or unset the session cookie. To use the
session variables again, session_start() has to be called.
OK, that's clear. You also mention in your post on SO that there's a chance that the user can directly navigate to this URI where you'll be running this code from. You really shouldn't be doing this and you should at the very least check user log-in data and the referrer string before starting the session and delete the session whenever user state changes. But let's say you didn't change your code and we can navigate to the URI in question. Now imagine this scenario:
- I have access to one of your legit user's computers, his/her network, can access your web application through same IP, and can collect his/her client-side session data
- I make a POST or GET request with no session data to your URI running this code
- I manually add these session fragments (session cookie, user-agent string) that I have access to in my modified browser
All of this is really easy to do and plenty of people with direct access to targeted user's computer would have the means and reasons to do such a thing, if they only had the knowledge to. And you're slightly lowering that bar.
Let's see what will happen.
session_start() will be called before the session was invalidated on your web server (which happens on
session_destroy()), effectively creating a new user session. I can then replace my new session data with the old (stolen) one, and your web application will have (based on my user-end session data) no reasons to suspect I'm not the user the session was created for in the first place. It will resume as if I was the previous user I stole session data from.
So how does this differ to session hijacking when using session handling routines in their intended order?
In a long discussion with @Xander dissecting PHP session handling routines, we've come to the conclusion that it doesn't change much anything in that sense. However, you also gain nothing by doing it so, and might result in breaking functionality of any third-party user session framework, if your PHP application depends on in. Quoting your related SO question "I'm concerned that if a user directly navigates to this page there may be an error destroying the session" does expose another concern, that you're essentially enabling exploiter a look into your user-end session data structure for free, without any user authentication before creating it. Saying "But I'm deleting it immediately!" doesn't really apply in this sense, as
session_destroy() "...does not unset any of the global variables associated with the session, or unset the session cookie." Saying it differently:
You just made session hijacking slightly easier, not the other way around!
TL;DR - So in short, you'll have to do it 'the boring, standard way' as that's in what order these two session changing routines were designed to run.