For as long as I can remember, there has been a trend to shift responsibilities from various OSI layers up, all the way into the application layer. My professor explained that that was primarily due to improvements in the physical layer — like being able to send (vastly) more than 8 bits at a time reliably over fiber. As bandwidth increases, the shape of congestion changes, but latency sticks.
Other factors are probably that "novel" concerns like security weren't properly understood at the time OSI model conjured.
Like any problem, system design is good to look at from different perspectives. The TCP/IP model groups the OSI's Application, Presentation, and Session layers together which would be fine if the accompanying descriptions for the TCP/IP model still described the concerns of the OSI's Presentation and Session layers (e.g. encoding, encryption, and SOCKS sessions in the context of web tech). But what I've seen is that the concerns of the Presentation and Session layers (from the OSI conceptual model perspective) are typically watered down or omitted altogether from explanations. For someone that is learning software engineering and who may end up as an application engineer or a network software engineer, this is not helpful at all.
While modern logical implementations don't typically adhere to the OSI model (separate layers with clear well defined boundaries), the concerns of the conceptual layers are still relevant, and still need solving in most applications. In practice you can have many different variations in logical implementations, e.g. applications or operating systems that blend functions for separate conceptual layers into the same binary file. The biggest problem that I see is that traditional explanations of the model (including the one I received at university) focus only on the conceptual overview, and don't relate the model to these more practical examples.
Your professors explanation touches on this somewhat, discussing how the Session layer concerns might be implemented logically alongside other Presentation and Application layer functions. Their comment about physical changes affecting how the models responsibilities might shift is valid too. You can see this with the TCP/IP offload capabilities of some NICs, where certain connection and checksum tasks can be delegated by the O/S to the NIC and may no longer be executing under the same process on the CPU. But you're still (for now) going to have a conceptual and potentially logical separation of concerns for Transport (TCP) and Network (IP) functions inside that NIC.
