Snark

Yes, that's a standard problem with asparagus designs.  The answer is to turn off symmetry when placing the fuel lines.  Just place every fuel line individually.  Yes, it's kinda tedious.  Yes, it means that the fuel lines won't be perfectly symmetrically placed, but in practice, as long as they're in approximately the right spot, it doesn't matter.
I might suggest attaching the decouplers to the top of the radial boosters rather than the bottom, so that the force of the decoupler will cause the booster to nose out from the ship rather than in.  This can help during launch, to prevent the ejected boosters from colliding with the central ship.
How did you "create" that booster that you're trying to hook on?  Did you save it as a subassembly?  Or did you click-copy it from one of the existing boosters?
If you loaded it from a subassembly, that's likely your problem right there.  Every subassembly has a particular "root" part, and it won't attach to anything except by that root part. This somewhat limits the usefulness, or at least can require you to jump through hoops to get the root part to be where it needs to be for a particular application.  If you're dead-set on 2-way symmetry, the easy solution is to just click-copy the inner booster (from the decoupler) and apply that.
However, rather than doing that, I'd suggest just 4-way-symmetry the boosters and asparagus them.  It'll be structurally stronger.  Just means that you need to manually place the six fuel ducts.
Also, that 2.5m adapter on the top of your center stack is going to generate a lot of drag-- suggest replacing it with a conical 2.5m-to-1.25m adapter, and then putting a 1.25m decoupler on top.  More aerodynamic, and IIRC a bit lighter, too.
Also, I'd suggest connecting the fuel ducts from the top of the booster stack to the top of the central core. It'll help with CoM issues during ascent.  As you have it right now, the center engine will be draining the radial boosters from the top down, which is the exact opposite of what you want for aero stability.

The fact that the Terrier has a lower TWR than the Swivel, and practical considerations generally favor doing higher TWR first, tends to muddy the waters a bit. 
What @Wcmille is driving at (though he states it more formally than this) is:  It's better to do your low Isp burns before you do your high Isp burns.
And the answer to that is "yes, all other things being equal."
What you're driving at is "is it always better to do your low-Isp burn before your high-Isp burn."  The answer is "yes, generally," but it's theoretically possible to go the other way.
For example, if I have two stages, one of which is Isp 350 and one of which is Isp 800, then in general I want to do the low-Isp one first, all other things being equal.  But suppose that the Isp 350 engine weighs 1 ton, and the Isp 800 engine weighs 1000 tons?  (And we're only talking about, say, 10 tons of fuel.)  Then clearly I want to ditch the heavy engine as soon as possible, it's a mass hog and accelerating it is a total waste of fuel, and in that case it would be better to do the high-Isp burn first.  So there's a counterexample to your formally-stated hypothesis. 
However, unless there's some gross disparity in the dry masses of the stages involved, it's better to do the low-Isp burn first.  That's because the high-Isp burn gets max dV out of a smaller mass, and the exponential nature of the rocket equation means that you pay a heavier penalty for mass that's closer to the payload in the burn sequence.  So being mass-efficient at the upper end is a good idea.

So there's going to be a certain minimum return speed  from any body, even if you have an ideal Hohmann transfer.  You can get all calculatory or spreadsheety if you like, but the easy way to calculate it is to do this:
got to http://ksp.olex.biz set up a transfer from Kerbin parking-orbit-at-70-km to whatever-planet-it-is (Yes, I know, we're going to Kerbin, not from Kerbin, this is deliberately doing it backwards so we get an arrival speed rather than departure speed) Look at what dV it tells you Add that to Kerbin orbital velocity at 70 km (about 2200 m/s) That's the speed you'll arrive at. That's the minimum.  If you have a crappy launch window and arrive in some other way than tangentially, then it'll be higher.  How much higher will completely depend on your trajectory, so there's no way to tell the answer without knowing the trajectory.
As for how to handle super-high-speed encounters:  Well, for any given ship design, there's a certain maximum limit that it can handle.  Sounds like you were well in excess of yours-- i.e. for that particular arrival speed for that particular ship, your situation was hopeless.  However, you can design a ship to withstand higher speeds.  The main way to boost the maximum survivable reentry speed is to try to reduce tons of ship mass per square meter of heatshield.
Ships that will have difficulty are long skinny lawn-darts with small heatshields on the front.  Ships that will do well and handle high speeds are pancakes.
This means:
use the biggest-diameter heatshield possible (even if you don't need one that wide to cover your ship reduce your ship mass if #1 and #2 are insufficient, you can add some "outriggers" sticking out to the side that are basically just mount points for additional forward-facing heatshields.  They're not actually shielding anything important (just the outriggers themselves, whose only purpose is to hold the heatshield)-- they're just there to generate additional drag and slow the ship down. If you do add outriggers as described in #3, put them at the back of the ship, so they'll act like airbrakes and help to keep you pointed forward.

Yes, as @steve_v pointed out, that's exactly the problem.  It's obstructing the port.
One thing to bear in mind:  there are decouplers and there are stack separators.  These serve a similar purpose, but they work differently:  when a decoupler blows, it stays attached to one of the two separated things (the side opposite the direction the little triangle is pointing), whereas when a stack separator blows, it detaches from both sides.
Therefore, decouplers are useful when you need to separate something that you're throwing away (like a spent booster stage), but they're not a good choice when you're keeping & using both of the separated things (which is in your case).  If you want to separate them and use both things afterwards, a stack separator is a better choice, since it detaches from both of them and therefore isn't hanging around and getting in the way afterwards.
In the particular case of your ship here, though, you can actually do even better than that:  as steve_v has already pointed out, you can just attach your probe directly on top of the rocket's docking port, without any decoupler or stack separator at all.  When you want to separate them, just right-click on the docking port and choose "decouple" and it will let go.
In other words:  a docking port can stick to anything (not just other docking ports) if you do it in the vehicle editor.  Once you're in flight, and after you decouple it, then it can only be re-coupled to another docking port of the right size.

You'll get a faster return with higher-level scientists, and faster if you have 2 scientists instead of one.
Each data point consumed generates exactly five science points.
As for "how long to fully deplete," I believe the answer is "forever."  The rate at which data is consumed is proportional to the amount of data present-- it's not linear consumption, it's exponential decay.  For example, you're currently getting 1.5817 science/day, which means it's consuming 0.3163 data per day (since one data point always makes exactly five science points).  Your current data amount is 468.65, so that's 0.0675% data consumption each day.  In other words, it will use up half of its data every 10.5 1026 days.  (thanks for the correction, @Wcmille)
If you run with physics warp or time warp on, or you come back after a long time, it's still the same set of numbers.  Science labs work at the same rate in game time, regardless of whether you're currently controlling them, and regardless of what speed (and type) of warp is happening.  So you can switch away to other ships, timewarp, etc. and the science lab will still be there doing its thing, and you get credit for the time it's put in.  So a typical usage scenario is to leave 'em running and go elsewhere, and every once in a while come back to transmit the science and top off the data.  Kind of like having a composting bin. 
I believe that multiple labs on the same craft don't particularly make any difference.  Each one works independently of the others.  Note that only the crew actually inside a lab affects its production rate, i.e. scientists elsewhere on the craft don't contribute, so there's no interaction there.  However, I believe if you have two labs you can process the same experiment separately in each lab and get double the science that way.  (I hasten to add that this paragraph is just what I think, I don't actually know this and haven't tested it.)
Location doesn't matter about how much science a lab generates, or how fast, while it's converting data into science points.  It does matter at the moment when you initially research an experiment:  i.e. it affects the amount of data generated for a given science result.  If you collect a science experiment on the surface of Minmus, you'll get more science data if you process it in a lab that's sitting on Minmus, than if you process it in one that's orbiting Minmus.  However, that only affects it at the moment that you process it.  Once it's processed, it's just in the "data" bucket, and data is data.
More stuff about how science labs work, for the curious.

Here's how it works:
Operating temperature
Both ISRU and drills have an ideal operating "core temperature."  For drills, it's 500K.  For ISRU, it's 1000K.  When they're exactly at that temperature, they're operating at 100% efficiency (more on what this means, in a moment).  If they're at any other temperature-- either hotter or colder-- then they're operating at lower efficiency.
They start out at whatever the ambient temperature of your ship is (usually a lot lower than 500K, so, crappy efficiency).  As they run, they warm up and become more efficient.
You want to have some radiators on your ship to keep them from heating past their max-efficiency temperature.  The good news is that the radiators are intelligent enough that they won't "overcool"-- that is, suppose you have more radiator capacity than you actually need, they won't shoot you in the foot by keeping your drills chilled and running inefficiently.  The radiators are smart enough to say, "I'm not going to cool this drill at all until it gets up to 500K, but then I'll cool it to keep it from getting any hotter than that at all."  So as long as you have enough radiator capacity to do that, you don't have to worry about having "too much"-- it won't hurt you (other than the cost and weight of lugging around the extra radiators).
 
What does "thermal efficiency" actually mean?
It's a multiplier on the operating rate of the drill or ISRU.  A drill running at 100% efficiency is pulling ore at the fastest rate it possibly can.  An ISRU at 100% efficiency is converting ore to propellant at the fastest rate it possibly can.  When the efficiency is, say, 50%, that means that the drill is mining at half speed, or the ISRU is converting at half speed.
 
What about power consumption?
My observation has been that you only pay electricity for actual results.  That is, if your drill is running at 10% thermal efficiency, then you're getting ore at only 1/10th the rate, and you're only using 1/10th the electricity.  In other words, a mining operation spends a certain amount of electricity per ore unit mined, regardless of the thermal efficiency.
What this means in practice is that you start up all your drills, they have really crappy thermal efficiency ('coz they're all cold), and you're using very little electric power.  As they warm up, they start pulling ore faster, and they also start drinking electricity faster.
So basically, the way drill power consumption works is this:
A drill that's running at 100% thermal efficiency, and which is actually mining ore because you have empty ore tank space available, pulls 15 EC/second of electricity. It does this regardless of the ore concentration and the engineer skill level.  If the ore is lower, or the engineer level is lower, this means it pulls less ore/second, but it's still pulling the full amount of electricity. Thus, higher ore concentration means less electricity needed per unit of ore. Thus, higher engineer skill means less electricity needed per unit of ore. Thermal efficiency is a multiplier on both the ore rate and the power consumption, so it affects ore-per-second but not electricity-per-ore. You only pay electricity if some conversion is actually taking place.  If your ore tanks fill up and you're not draining them via ISRU, then your drills stop drawing power.  If your LFO tanks fill up so your ISRU can't convert any more, it stops drawing power.  If you're ISRU-converting and ore-drilling at the same time, and you have ore in your tanks but its level is dropping because the ISRU is converting faster than the drills can drill, then the ISRU power consumption will drop a lot when the ore tank reaches zero, because then the ISRU will be throttled to the paltry incomng ore rate from the drills, which is a lower rate. Ore mining is really really slow, so you want your ore drills running at 100% thermal efficiency.  To do that, all you need to do is 1. make sure you have radiators on the ship, and 2. wait.  The drills will naturally warm up as they operate until they reach optimum operating temperature, and the radiators will then stop the drills from getting too hotter.
As far as ISRU is concerned, it's not worth worrying about, it'll generally take care of itself.  Besides, ISRU capacity is so much higher than drill capacity that it's never a bottleneck-- one ISRU can cheerfully keep up with the output from a dozen drills.
 
What's the practical upshot?
Land on good ore concentration, and use a good engineer.  This doesn't just affect the speed of your operation:  it also affects how much electricity-per-resource you need to spend.  So it can make the difference between a ship that runs happily forever, and one that keeps running out of power. Fuel cells are of particular interest.  A mining/ISRU ship turns electricity into LFO.  A fuel cell turns LFO into electricity.  There's a certain break-even point, above which fuel cells generate more electricity than the LFO they consume, and below which they don't.  You really want to be above that break-even point, because it's the only way to keep your rig running through the night.  So make sure you're on a good ore spot, unless you want to shut down each night. Have enough radiators on your ship.  Doesn't need a huge amount of them, but have enough.  If you have more than you need, it doesn't hurt anything. Be aware that your initial power consumption will be a lot lower than your steady-state consumption.  Drills take a long while to warm up, like an hour or so of operation.  They won't be drawing max power until they warm up to 500K.  So after you start drilling, open up the drill's menu, watch the temp, and then timewarp at 10x or 50x until it gets up to 500K.  Now you can see how fast your ship will really mine, and whether it has enough electricity supply.  

Here's my two cents:
First-- I assume you're doing this just for the heck (challenge) of it rather than practical reasons?  I only mention it because simply launching a mission that peeks outside Kerbin's SoI and returns will get you to level 3, and there's really not much practical benefit to going all the way to 5.  So I'll assume that that's not a factor, and the simple answer of "skip the whole mission and do an SoI peek" is off the table.
You mention that adding a landing would skip the need for a flyby.  In that case, I'd suggest that it's worth landing on Pol.  Pol is so tiny, and its escape velocity so low, that if you're already in orbit around it, you might as well land.  Would take just a couple of minutes and minimal fuel.  I assume you're going to be sending a mission with a whole lot of kerbals on it so that you can train 'em all in one whack.  In that case, it's fine not to plant flags (when you've got a dozen or more kerbals, it's an incredible pain to take them all out one by one to plant flags and get back in again; IMHO the "plant flag for XP" mechanic is a silly one, landing should be sufficient), but simply landing and taking off again is quick and easy.
More to the point:  it's faster, easier, and takes less of your time than setting up an additional inter-moon transfer.  For example, if you can skip  Bop (which is another oddball orbit that takes some fiddling to get an intercept with), so that you just do flybys of the three inner (circular, coplanar) moons, your life gets a lot easier.
One of the handy things about those inner moons is that they are 1. packed close together, and 2. lugging large SoIs around with them.  This means it's very easy to set up flyby encounters with them.  All you need to do is make a very elliptical orbit whose Pe is down close to Jool (below Laythe), and whose Ap is quite high, and you can get flybys practically for free.
So here's the minimal-dV, minimal-elbow-grease flight plan that I would suggest:
Arrive from Kerbin. Use a reverse gravity assist from Tylo or Laythe to capture to capture to a highly eccentric equatorial orbit of Jool with a very low Pe and a high Pe that's up around Pol. This takes care of one of your flybys. It expends minimal dV, since, first, "highly eccentric with low Pe and high Ap" is the cheapest-dV orbit to capture to, and, second, the gravity assist is helping. Spend some time looping around Jool to get flybys of Vall and whichever one of Tylo-or-Laythe wasn't the one you used in the gravity assist. Your orbit crosses all of them, so you can get this for practically zero dV if you're willing to just watch and wait. That said, you can hurry it along a bit by doing tiny-dV burns when you're way out at Ap.  This can both speed up the process, and help avoid getting flybys that are too close and end up disturbing your orbit too much. Once you have all your flybys, set up an encounter with Pol.  If you do this when you're out at Jool apoapsis, it shouldn't take a lot of dV. Arrive at Pol, capture to orbit. Land. Take off, dive to Jool, slingshot home. I would also add that you could top off your journey with a Mun flyby, for minimal effort and almost no dV expenditure.  Given that you're coming home all the way from Jool, it'll take a year or two to get back.  For a journey that long, only a very tiny tweak at the start can change the date of your Kerbin arrival by several days.  So you can use a little nudge at the start of your homeward trip to delay or advance your Kerbin arrival by a day or two, so that the Mun gets in the way and you brush its SoI on the way in to Kerbin.  Practically free, and it buys you a few extra XP.  Not many, but hey, why not? 

Go to the list of completed contracts (that vertical stack of green buttons at the top right corner of the screen). At the bottom of the list (you may need to scroll down) is a new bright blue button with a globe icon on it. Click that.
Be careful not to delete it, if you do it's gone forever and there's no way to review your world firsts.