When a macro does the wrong thing, most people rewrite it. You almost never need to: you need to see what it saw. `Debug.Print` writes to the Immediate window as the macro runs, so you get a log of what each row actually held. F8 steps one line at a time with the sheet visible beside you, and clicking the grey margin sets a breakpoint that runs at full speed until it reaches that line. Nine times in ten the answer is that a value you assumed was a number is text, and the comparison you wrote has been doing something quietly different all along.

Sub FlagLargeItems()
    Dim lastRow As Long, r As Long, flagged As Long
    lastRow = Cells(Rows.Count, 1).End(xlUp).Row

    ' Ctrl+G in the editor opens the Immediate window this writes to.
    Debug.Print "--- run " & Now & " · rows 2 to " & lastRow

    For r = 2 To lastRow
        ' Click the grey margin beside this line for a breakpoint,
        ' or uncomment Stop to break here every time.
        ' Stop

        ' TypeName is the one that solves it: "Double" vs "String".
        Debug.Print r, Cells(r, 2).Value, TypeName(Cells(r, 2).Value)

        If Cells(r, 2).Value > 10000 Then
            Cells(r, 3).Value = "Review"
            flagged = flagged + 1
        End If
    Next r

    Debug.Print "flagged " & flagged & " of " & (lastRow - 1)
End Sub

Paste into the Visual Basic Editor (Alt + F11 → Insert → Module), then run and save as macro-enabled (.xlsm).

• A loop that flags too many rows, or none at all.
• Finding the one row in four thousand that breaks the run.
• Checking what a cell actually contains before blaming the formula.

A simulation — press Run to perform what the macro does to a sample workbook.

• MsgBox in the loop — Works, and stops the macro dead on every row waiting for a click. Fine once, miserable over a hundred rows.
• The Watch window — For keeping an eye on one variable across the whole run instead of printing a log.