I suspect they're part of a connection pool & therefore haven't idled out because they're being used frequently.
v$session merely means there isn't a SQL statement being executed at the exact moment you check
If they're part of a connection pool they're doing their job properly by being logged in for long periods of time. The whole point of connection pooling is to remove the need for lots of logons/logoffs & keep persistent sessions for fast query startup - there's a much larger overhead logging in execute one query, then disconnecting every time.
To get the last activity time for each session:
select username, UPPER(program), logon_time,
floor(last_call_et / 60) "Minutes since active", status
where UPPER(program) LIKE '%W3%'
order by last_call_et;
I'd advise against killing sessions unless you know that doing so will not cause problems on the application side (trying to use a session that's been killed, for example).
It may be the case that you're looking at an incorrectly configured connection pool which creates hundreds of connections once the app starts up - the connection pool may be an order of magnitude bigger than it needs to be. I suggest reaching out to the developers/application support staff & taking a look at how the connection pool is configured.
Having done a bit of research, w3wp.exe is the IIS Application Pool Process - you almost certainly want to talk to your IIS webserver admins to help get to the bottom of the connection pooling configuration.