EDIT: In the real world, the most influential determining factor for BGP path selection is usually just 'best AS path' which means 'shortest' or fewest AS hops to reach the advertised network.
Assuming AS7 wants to reach IP addresses advertised by AS1, and no other factors are configured (Weight, MED, AS Path Prepend, etc.) then it will always use the path via AS5 because it is a single hop vs 3 hops via AS4. AS5 will always use the direct connection to AS1 unless the link is down or manually messed with via AS Prepend, Weight, MED, etc.
The only scenario where one might do that is if the link between AS1 and AS5 is a particularly 'expensive' (metered) or particularly slow/small link like a tiny serial line with 56k bandwidth compared to 1 gigabit lines on the other links. Realistically that would never happen because even a functional 56k link would never be a viable backup to a 1 gigabit link unless literally all you care about is route propagation and no actual user traffic.
See here for more info on BGP best path selection:
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
As described in the comments section after the original question, it is possible to create an effective routing 'loop' where a destination network becomes effectively unreachable either through gross misconfiguration or intentional misconfiguration but it is actually fairly hard to do unless you are trying to 'massage' routes or influence a path for a network and make a serious mistake.
For example, if a network directly connected at AS6 wants to reach a network at AS1 and has received a route advertisement from AS5 describing a single additional hop to reach AS1 then obviously traffic from AS6 to AS1 will transit AS5 because the router at AS6 will see an advertised route from AS7 as being many more hops vs. the route via AS5. We can also assume from the offered diagram that AS5 advertised that same route to AS7 and AS7 chose it as best and installed it in its route table because it is shorter than the one offered from AS4.
In that scenario, if the administrator at AS5 has done something foolish or evil to advertise a route that they do not actually want to use for traffic from peers, then they may do something (probably a policy route that will create pain) to manipulate traffic at their network edge and redirect it to AS7 instead.
Once the traffic reaches AS7, the router at that network will check its route table and find a route advertised by AS5 that has fewer hops than one it was offered from the peer at AS4. The router at AS7 will have long decided that the path for the desired network is best via AS5 compared to the path via AS4 so traffic will be sent to AS5. This is not what I would call a 'routing loop', per se (as I mentioned in my comments, it would take at least 2 misconfigured routers to effectively create a true loop). In this scenario, BGP is working as intended and the route situation is sane and functional but is being overridden by an administrator mistake/malfeasance.
Note: This is not how you handle this kind of situation.
If the administrator of AS5 has a reason to not allow traffic over the link from AS5 to AS1, they need to either disable the link or peer session, use an IGP route association if appropriate (for private/intraorg traffic), or a simple static route/policy route for their own traffic to reach AS1 as desired. Advertising to peers that you have a valid path to a network and then intervening to send the traffic destined to that network via a different path is nasty and will result in unpredictable issues (as mentioned) and probably some upset emails and phone calls. Or, assuming the situation described above where traffic simply no longer reaches AS1 at all, the administrator at AS7 would simply de-peer AS5 until they get their issue straightened out.
To actually handle the case where the administrator might want the link and peer session to work but be a low priority link (for backup or something), they can simply do an AS Prepend or Weight configuration for the advertisements of that path. If they don't want traffic to normally transit via their link from AS5 to AS1, they can prepend the AS Path with a few 'hops' to make it look like a much longer path than it actually is and traffic will go the other way without further intervention unless the path via AS7 fails for some reason (which would leave AS5 as the only option).
As for BGP having/not having a loop prevention mechanism: it absolutely does, though as with most things it is not perfect. BGP uses a scan of advertised networks from a peer for a number of issues before installing an offered route in the BGP Database, or eventually the FIB (after selecting the best path).
From my previous link: Cisco BGP Best Path Algorithm, you can see there is a section on why routes might be ignored during BGP path selection and one of them is: "Paths from an external BGP (eBGP) neighbor if the local autonomous system (AS) appears in the AS_PATH"
That is to say that if Router A receives an advertised path with its own local AS in the advertised path, it will reject that path from consideration as a possible best path automatically. (Though this too can be overridden via manual configuration.)
That loop prevention feature is quite effective in most cases but much like Spanning-Tree Protocol can usually prevent a loop, it is possible to defeat it if the administrator works hard enough to do so.
Of course, IP traffic also includes the concept of the TTL which prevents traffic from simply bouncing between routers, or passing over and over through the same set of misconfigured routers forever. That helps alert users and administrators to a possible problem if traffic either can't reach a destination network, or has to pass through an excessive number of hops to do so.
To more specifically answer the actual text of your original question:
So what happens if AS 7 chooses {AS 1, AS 5} as its favored path, and AS 5 chooses {AS 1, AS 2, AS 3, AS 4, AS 7, AS 6} as its favored path? (as far as I know these choices should be possible depending on the configuration)
The simple answer is: AS5 would never do that unless the administrator has made a serious mistake or intentionally misconfigured something. The only case where I can imagine AS5 would see the long path as better than the single directly connected link is if the peer session between AS5 and AS1 were intentionally weighted or prepended to appear to be very undesirable. AND if that were the case, then AS5 would advertise it as such to AS7 and AS7 would never install it as its best path so it would agree that the longer path would be better. Hence, no loop.
