I think this is what, in rugby, they would call a 'hospital pass'.

As someone who has fixed much code like this, I am going to hit some highlights only. If you manage to fix these highlights, I would love to see the revised code in another question for the second round. Because the job you have undertaken will take many passes to get right (but it will be worth it).

Set yourself up for success

[…] but the original author wants me to keep the select [...]

If you are fixing and maintaining the code, then it must be written in a way that makes it easy for you to maintain. If you are fixing this and someone else must maintain it, then be that nice coder and make it easy for them to maintain. However, moving the user to view particular cells in a work process is a user requirement that you should keep in mind.

Option Explicit at the top of every module. Just a reminder - you might already have it there.

User Named Ranges in the sheets. It will make future maintenance so much easier. And it will make the current code easier to understand - .Range("DateEntryDate") is easier to understand than .Range("$B$3")

Exit early

For performance reasons alone, always find the reasons not to run the code at the very start and exit. At the moment, if I make a change in $ABC$678023983, this code is going to fire and run. What a waste of time and cycles! Example:

Private Sub Worksheet_Change(ByVal Target As Range)
Dim validRange as Range
    Set validRange = Intersect(Target, Me.Range("$B4:$B11")) '<-- wow, a named range here would be good.
    If validRange is Nothing Then
        Exit Sub ' <--- explicit exit, easy to see.
    End If

    If Target.Cells.Count > 1 Then
        Exit Sub ' <-- always manage the range size!
    End If

    ' … other code 
End Sub

Qualify your ranges

Most of the code is written with unqualified ranges (implied action on the active sheet).

Range("A400:A411").EntireRow.Hidden = False

However, this assumes that the active sheet continues to be the sheet that the _Change event occurred in. Never make that assumption. Remember this code?

Range("B101").Select

This means that the active cell will jump. With future modifications to the code or workbook, this may even jump to a different sheet.

In addition, the code calls some utility functions (e.g. Hide_all) - these may also alter the active sheet.

Having noted that, what is with With wsDE? There is an entire With block that in no way whatsoever that references the object (wsDE)!

Code readability

Don't use the line joiner, it can lead to confusion:

        Case Is = "$B$4": Hide_All
            Select Case Range("B4")
                Case Is <> ""
                    Range("A100:A199").EntireRow.Hidden = False
                    Range("B101").Select
                    Sheet5.Visible = xlSheetVisible 'Confirmation-Incoming
                    Range("B5") = ""
                Case Else: Range("B5").Select
            End Select

Should be:

        Case Is = "$B$4"
            Hide_All
            Select Case Range("B4")
                Case Is <> ""
                    Range("A100:A199").EntireRow.Hidden = False
                    Range("B101").Select
                    Sheet5.Visible = xlSheetVisible 'Confirmation-Incoming
                    Range("B5") = ""
                Case Else
                    Range("B5").Select
            End Select

All of a sudden, the indent levels and code scope is easier to understand. The Else becomes more obvious. Much easier to read.

Declare variables closer to where you are going to use them, and in the same scope.

Dim Unique_Identifier As String
Dim Wire_Type As String

Took me a while to work out if they were actually used.

What is next?

If you address the above points you will end up with some slightly cleaner code. You will recognise yourself that it requires more work. However, you will have a cleaner foundation to figure out the remaining inefficiencies. One step at a time and you will get there!