Consider VMX1 and VMX2, connected via ge-0/0/0.128 and ge-0/0/0.129, each exporting 2 static routes with shared /24 LAN, ge-0/0/1.1, as the Next-Hop into ISIS...

The static route which is unique is properly exported into ISIS:
regress@vmx1# run show route 1.2/16
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
1.2.3.2/32         *[Static/5] 00:00:18
                    >  to 192.168.42.100 via ge-0/0/1.1
1.2.3.3/32         *[IS-IS/18] 00:00:08, metric 2
                    >  to 199.8.216.32 via ge-0/0/0.128
1.2.3.4/32         *[Static/20] 00:07:20
                    >  to 192.168.42.100 via ge-0/0/1.1

regress@vmx2# run show route 1.2/16
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
1.2.3.2/32         *[IS-IS/18] 00:00:33, metric 2
                    >  to 199.8.216.33 via ge-0/0/0.128
1.2.3.3/32         *[Static/5] 00:00:23
                    >  to 192.168.42.100 via ge-0/0/1.1
1.2.3.4/32         *[Static/20] 00:03:42
                    >  to 192.168.42.100 via ge-0/0/1.1

The 1.2.3.4 static route which is configured on both routers prefers the static, even though preference of 20 is higher than ISIS' 18.

After removing the static route, the ISIS route is there:
regress@vmx2# deactivate routing-options static route 1.2.3.4/32
regress@vmx2# commit
regress@vmx2# run show route 1.2.3.4/32
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
1.2.3.4/32         *[IS-IS/18] 00:00:16, metric 2
                    >  to 199.8.216.33 via ge-0/0/0.128

Add the static route back, and we see the expected output:
regress@vmx2# show | compare
[edit routing-options static]
!     active: route 1.2.3.4/32 { ... }

regress@vmx2# commit
regress@vmx2# run show route 1.2.3.4/32
inet.0: 21 destinations, 22 routes (21 active, 0 holddown, 0 hidden)
1.2.3.4/32         *[IS-IS/18] 00:01:07, metric 2
                    >  to 199.8.216.33 via ge-0/0/0.128
                    [Static/20] 00:00:04
                    >  to 192.168.42.100 via ge-0/0/1.1

The ISIS behavior is different than OSPF.

If both gateways use ISIS route, there's a loop, so ISIS route is suppressed by RPD/kernel until the static route is gone. One node must prefer the static route.

Further Explanation:

ISIS only uses metric for route calculation, not preference. preference is for RIB to decide which route to prefer.

As per OSPF RFC 2328, section 16.4(2) states that if LSA was originated by the calculating router, that LSA will be skipped for route calculation.  

In this case, the LSA for 1.2.3.4 originated by vmx2 will be skipped at vmx2 for route calculation, and based on the LSA received from vmx1, OSPF route becomes the active route. This is not the case with ISIS.

If the use-case is to have the ISIS route as best route and the static route as backup, while exporting through the policy, we can try configuring metric for the static route to a value higher than that of isis at vmx2:

set policy-options policy-statement ISIS-EXPORT term static-to-isis from protocol static

set policy-options policy-statement ISIS-EXPORT term static-to-isis then metric 20

set policy-options policy-statement ISIS-EXPORT term static-to-isis then accept

.....

set protocols isis interface ge-0/0/0.128 level 2 metric 2

This will set metric to 20 for all static routes exported into ISIS and will make ISIS routes active in RIB and the static route as backup.

But, with this configuration, load-balancing cannot be achieved. That is, ISIS will always be the preferred route and only when ISIS goes down, static route will be preferred.