You're not predicting there, you're assuming.
In some cases you can already predict its not going to work. As for example alot of narrow ways is in many cases already going in a bad direction. Taking areas into height is also risky and if there is no reasoning behind it then again, its often an indication your idea is flawed. These predictions can be made quite safe. Since if you had a reason to do so then thats part of the idea you want to make. Getting it to work is sometimes the chalenge. Otherwise i could have scrapped intercept instantly.
Predicting implies theres a science behind design, a concrete way of doing things that cannot be broken. Players are cats, they'll do things you don't want them to, they'll react to the same situations in different maps differently, they'll expand to fill space in ways you never intended, etc.
Players are just like computer code. If you dont properly trigger them they wont perform what they should. So in a certain way you need to guide them. The rest is just rand();
Don't try to predict players. Give them cool situations and watch them have fun. Find the parts that give the least amount of fun and fix them.
Do predict the basic behaviour, but dont try to strictly predict them. If you make a doorway with option left or right where left is more ideal. If they go right just let them. This is indeed something you cant predict and is part of the playtesting requirement. A fully static map isnt good after all.
Being quick to scrap can be bad. What time are you saving? What are you in a hurry to do? Take your time with ideas. Its great if it works out right away but sometimes ideas need breathing space. You thought of it for a reason, so theres something about it on some level that interests you.
It depends on what you scrap. Some things have been proven to fail often. If you think your idea isnt going to work, dont use it. There you save time. Scrapping a whole map rarely falls under this, and if it does you often just scrap the idea. Once you have a full map you can still change the gamemode. So on that scrapping is indeed less efficient. But this already got past the first few thinking moments for a reason.
Gameplay can be heavily informed by a theme and it keeps the believably of the map high, but if you didn't go into the idea using the theme for gameplay it'll be easier to change themes, yeah. Its dangerous to change horses midstream.
A theme can be part of the gameplay. And your specialy constructed area is most likely made to be a full part of it (capture area's etc). And for that reason you can adjust the control point to the theme. But you can still do that afterward, rough placeholders can still be changed to nearly everything else. And this is what you should do on detailing. But it can also be counter productive since beauty can hinder gameplay. And when players get anoyed it isnt a good thing.
A theme simply makes it easier for some people to get their map into a shape as they got reference images. This isnt the case for everyone however. And its also wise to not strictly follow a certain theme because it will give you restrictions that are going to hinder.
For intercept i used a pyramid, but the facade is something that is highly unrealistic. But since i found gameplay more important i was still able to get it to fit nicely. And that is only because the gameplay shape has been set, i only had to match the visuals.
There are many solutions, and my own ones might be the opposite of yours. But both are true. It depends on the mapper. Im one that focusses on gameplay and decides to detail afterward.
(also, i mainly play just 3 gamemodes in tf2: payload, A/D cp, mvm)
