In my experience, the qualification you made "as long as the data look just like that" is a rare condition when receiving raw data from people.
If the data are guaranteed to be already in order by ID, then there is no need to sort -- you could remove the PROC SORT step from my code and just add the NOTSORTED option to the DATA step BY statement. That would allow you to use FIRST.ID and LAST.ID without needing to SORT. But, depending on other people to send you data that is ALWAYS in order is not a best practice, in my mind, for an on-going, production type system. So generally, I put a sort into my code because I consider it to be a best practice, because then I am not relying on anyone else. After a sort, I know that the data is in order. And, unless we were talking about millions of records on a somehow constrained system (which we don't know), the sort isn't, by itself, going to cause the program to be less efficient.
The OP did not say whether this was a one-time conversion of the multi-line input data to a SAS dataset or whether this was an on-going (daily, weekly, monthly) add of records from one system to another. It is premature, in my opinion, to talk about efficiency until you know the whole picture of the process and all the parameters involved in the requirements, including the sizes of machines involved, the sizes of the various files and the level of data integrity that is required for the tracking of the SAS dataset.
For example, I used to work for lawyers and I had to be ready to go to court and explain my code to non-technical people, if they had questions about how the data files from the "other side" were treated in order for our side's analysis to be done. In that case, efficiency was not the primary requirement. We frequently would run 1 datastep program for each change we wanted to make, with a PROC PRINT before and a PROC PRINT after so we could point to the 1 thing and only the 1 thing that was changed. It was highly inefficient programming, but also highly understandable by lawyers, judges and a jury.
An alternative solution is only that -- an alternative. It is up to the OP to test/benchmark and figure out whether there's even a big enough efficiency gain to offset using simpler code, since programmer maintenance time is also one factor in any "efficiency" equation.
cynthia