I think the reasoning behind the request to allow tempdb to be in-memory is two fold.
The process of application login creation for a dataserver is already fairly arduous with a ton of audit requirements and sign-off before approval is granted. Amending this process to also include step to configure & bind to specific temporary databases is technically straightforward, but a bureaucratic nightmare.
If there was an option to NOT bind certain logins/applicationsthat would make maintenance much more straightforward (and may even negate the need for the imdbtempdb?) I.e, bind everything apart from sa_role logins etc.
On a given dataserver there may be 10000 logins and a thousand applications. Many legacy or tactical apps are difficult to track down to particular groups and establishing clear ownership and responsibility is not always straightforward. Whilst I was working on your side, I too, always used to say, it isn't difficult :-) It's the rigmarole around it, particularly when there are ever-tightening controls that make things difficult.
As you say, there is still always going to be activity on the system tempdb, in which case how should it be sized assuming you did move everything you could across to imdbs? As for lwps, they are assigned a database id of 2, but are they really 'in' tempdb, in as much as taking space in the system segment? The plan will be in the proc cache and there will be an object structure but I don't think it'son-disk. (?). I guess if tempdb were imdb, then as you say there would have to be a mechanism to be able to extend it.
