List of namespaces with no information

 First, to clarify, do you mean that the deleted user's folder is still listed in the /2/team/namespaces/list response? I can't seem to reproduce that. Can you share the steps you're following to produce that?

Is there any way to permanently delete the file?

To operate on team owned content, you would use the "member file access" feature, e.g., to use the /2/files/delete_v2 and/or /2/files/permanently_delete endpoints. I can't say off hand if this will work in the particular scenario you're referring to though, as I'm not sure what the state of the team is that you're referring to, as above.

Are we able to get metadata of who was the one who added the file/folder in the first place?

Like the above, you would use the "member file access" feature, but for /2/files/list_revisions.

how would the administrator get access to review this folder and delete it without resorting to any API calls?

 I can only speak to the API functionality. For help with non-API areas of the Dropbox product, please contact support.

Is there any difference in API calls between the new "team spaces" config and the old one?

The difference between teams using or not using the team space configuration is how the team is structured. It doesn't fundamentally change the API calls necessary, except that you may need to use the 'Dropbox-API-Path-Root' header in some situations where you wouldn't otherwise need to. I recommend reading the Namespace Guide for information on this. The Content Access Guide may also be helpful.

Is there a better way to do what I want to achieve? 

If you're interested in specifically building a UI that lists contents from the user's perspective, you may want to start from /2/team/members/list[/continue] and listing the contents for each, as opposed to /2/team/namespaces/list[/continue], as the latter is more user-agnostic. (I.e., it's focused on giving distinct namespaces, not organized by user.) That's up to you of course though.