I opened turned OFF the dialog and checked the URL it uses to launch display form. As the normal list behaves, it is first invoking the "listform.aspx" page with query string. The "listform.aspx" page normally causes redirection to appropriate page type specified in the query string. Due to the 404, browser was not displaying the correct final URL. So I just launched the developer tools and checked the HTTP request/response cycle.
The "listform.aspx" is sending 302 for redirection but the location it was referring to the original list. As the original list does not have the new created display form of the new list. It was returning 404.
Then we removed content type ID from the query string and it was working fine. We further investigated and checked if it refers to wrong content type. It was referring to the content type available with the new list. So content type is not the issue.
Why "listform.aspx" referring to the original list?
I de-compiled the code of the "listform.aspx". The "listform.aspx" page invokes a method of ListFormWebPart. This method prepares the final display URL based on the "DisplayFormUrl" property of content type.
The PowerShell script confirmed it that the problem is with the content type display form URL. The content type is right but it's property has wrong reference.
We updated the DisplayFormUrl in script and it started working. Great job!!!