Because then the UI will be confusing - the same place and action (clicking in the top) will affect either application or window manager. Also, sometimes you want to drag tabs around to e.g. reorder them or move to a new window.
Clicking != dragging. Same place, different action. Just because dragging starts by clicking doesn't mean that the computer should react in the same way. Double-clicking also starts by clicking, but most computers are perfectly capable of reacting differently to a double-click.
Switching to a tab upon clicking the top pixel is also perfectly consistent with what usually happens when you click on the chrome of any window:
1) Clicking on the title bar (top pixel) = Switch to window, and activate the element at pointer location, which in this case is a tab. Try clicking on the "Minimize" button of any background window to see this paradigm in action. The window is brought to the foreground and immediately minimized.
2) Clicking on an actual tab = Switch to tab.
3) Dragging on the title bar (top pixel) = Drag the window.
6) double clicking the title bar = Maximize/Restore
And then you double-click the titlebar instead of the tabbar by mistake and your window jumps away.
Or just have a stupid option and let the user decide. Maybe have that context-sensitive behaviour as default, but let me say that I want the title bar to be the title bar and tab bar to be the tab bar and have the two not mix together.
If you click, it's a tab. If you drag, it's a window. What's so difficult about that? There's no reason to click on a window that is already fullscreen, anyway. (OP's problem only occurs if the browser is fullscreen.)
Because then the UI will be confusing - the same place and action (clicking in the top) will affect either application or window manager. Also, sometimes you want to drag tabs around to e.g. reorder them or move to a new window.