A bug

First of all, you get perfectPrice = 0, perfectIce = 0, and undefined customers for temperatures below 50 °F. I guess that's not what you want, so avoid such strange situations by cleaner coding. One possibility is

// Leaving local variables undefined is fine in this case
// ... as Java enforces that they get set before use.
double perfectPrice;
int perfectIce;

// Note that for temperatures above 90 your code is assigning
// every variable four times.
// That's why I had to reverse the condition order.
if (temperature > 90) {
    ...
} else if (temperature > 80) {
    ...
} else if (temperature > 69) {
    ...
} else if (temperature > 58) {
    ...
} else {
    throw new IllegalArgumentException("temperature=" + temperature);
}

Or drop the first condition (when you can sell lemonade at 1000 °F, you can sell it at −459.67 °F as well). Usually, such conditions are actually separators for the ranges and there's one fewer of them.

Separation of concerns

    if(temperature > 58){
        switch(weather[randomWeather]){

This makes your method much less usable. What random? The method should accept as its input a temperature and a weather. Leave the randomness outside.

What is it all about?

Ask yourself, what are you actually doing? There's temperature, weather and various variables. This looks like a 3D table to me (one dimension is what variable gets set). That's not nice, and get even uglier when transformed in a lengthy code.

So let's create (using Lombok)

@RequiredArgsConstructor @Getter class Recipe {
    private final double perfectPrice;
    private final int perfectIce;
    private final int customersDelta;
}

Working with Strings representing one of n possibilities is wrong, so let's create

enum Weather weather {SUNNY, HAZY, CLOUDY, OVERCAST, RAINY}

and now you could rewrite your if-cascade to something like

if (temperature > 58) {
    switch(weather[randomWeather]){
        case SUNNY: return new Recipe(0.23, 5, -20);
        ...
    ...
...

It's shorter and more structured, but still ugly. What about a table?

A Table

With aggregating the recipe into a Recipe, we turned it to a 2D table. Unfortunately, the entries are recipes, i.e., composite things and don't fit well into a CSV table (which would be my clear favorite otherwise).

But still, it is a table. I'd structure it like this

Threshold; Weather; PerfectPrice; PerfectIce; CustomersDelta
58;        SUNNY;   0.23;         5;          -20
58;        HAZY;    0.21;         5;          -25
...

Now you can read it from an external file or create a simple method so that you can write

new RecipeTable()
.put(58, Weather.SUNNY, 0.23, 5, -20)
.put(58, Weather.HAZY,  0.21, 5, -25)
...

Then you'd need some code to query the table. It's not exactly trivial, but I (or someone else) can help you in another CR if you try.

To equal or not to equal

You're using conditions like temperature > 58, where temperature >= ... feels much more natural. If the input is a double, this hardly matters and > can be simply replaced by >=. If it's an int, then you can replace > 58 by >= 59.

A formula

Assuming that for sunny weather and 58 °F the perfectPrice = 0.23 and for sunny weather and 69 °F the perfectPrice = 0.25;, I'd bet that the perfect price for 64 °F is much closer to 0.24 than 0.23. That's why a formula should be used, something as simple as linear interpolation should do.

For beginners

This all can get a bit complicated and I'd recommend top concentrate on the simple things for now.

• Create the enum Weather and the class Recipe (you don't need to use Lombok, just write the boring stuff manually).
• Using if and switch instead of the table is not nice, but acceptable, when done right. Here, this means to really return when a condition is met (otherwise debugging is a pain).
• Always think about what happens when no condition is met.
• Always think about the method's inputs. You're giving no method declaration, as it was an irrelevant thingy. But it's actually the mosty important part.

Bug in the loop code

You're getting negative customers, because of what I wrote in the very first paragraph:

// Note that for temperatures above 90 your code is assigning
// every variable four times.

You're also executing customers = customers - tempCustomers[p]; multiple times. Just don't do it and write a method returning a result (containing customersDelta) instead of modifying variables. It's cleaner and less error prone as you can see just now.

Update for the loop code

With the condition

if (temperature >= 59 && temperature <= 69){

you've fixed the problem, but it's not nice as the bounds get repeated. Using "else-if" should be enough.

customers = customers - 20;

This is strictly worse than the original

customers -= 20;

If you don't have the time to create class Recipe (which you really should), then don't do it. But note that without it, you can't write a simple method computing and returning a value (as you can't return more than one thing).

If you don't have the time to create enum Weather, then at the very least define the string constants like

public static final String SUNNY = "Sunny";

This way, you program won't stop working when you fix the typo ("Rainny" -> "Rainy").

I don't thinks it's a loop you need.

Using a formula

The values per weather type and temperature range seem to follow a pattern that perhaps you can capture with a formula. However, on closer look, I see some irregularities that break the pattern, so probably this won't work well. See the next point.

Using a table-driven approach

When you have multiple variables with many possible combinations, and irregular values, a table-driven approach typically works better. The code will be both easier to read and maintain.

In this example, you have data (price, ice, customers) that depend on weather conditions and temperature range. It's easy to see what's happening if you rewrite the value mappings in a table:

weather | temperature | value
-----------------------------
sunny   | > 58        | 0.23
sunny   | > 69        | 0.25
...
hazy    | > 58        | 0.21
hazy    | > 69        | 0.23
...

Among the possible ways to accomplish this in Java, you could:

• Create a Map<Key, Double>, where Key is a simple class to contain the fields necessary for the mapping, in this case weather type, and temperature range

• Create a Map<String, Double[]>, where String is the weather type, and Double[] contains the values for each temperature range

There could be other ways too.

Other concerns

Looking at this code:

    if(temperature > 58){
        // ... set perfectPrice, perfectIce, customers
    }
    if(temperature > 69){
        // ... set perfectPrice, perfectIce, customers
    }
    if(temperature > 80){
        // ... set perfectPrice, perfectIce, customers
    }

What do you think will happen when temperature is 81? The code will set perfectPrice, perfectIce, customers again, again, and again. The conditions should have been chained with else if, or you should have used another way to exit those blocks after setting the values.

Avoid magic strings

"Sunny", "Hazy", "Cloudy" and the others are repeated multiple times. If you make a typo in one of them, the compiler can't help you spot the problem. You should at least convert these to static String constants, or possibly even an enum (if you don't need to add new types dynamically).